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Introduction 

Todo gira en tomo de una vision. Un sistema complejo toma forma cuando alguien tiene 
la vision de como la tecnologfa puede mejorar las cosas. Los desarrolladores tienen que 
entender completamente la idea y mantenerla en mente mientras crean el sistema que le 
de foma. 

El exito de los proyectos de desarrollo de aplicaciones o sistemas se debe a que sirven 
como enlace entre quien tiene la idea y el desarrollador. El UML ( Lenguaje Unificado de 
Modelado) es una herramienta que cumple con esta funcion, ya que le ayuda a capturar 
la idea de un sistema para comunicarla posteriormente a quien este involucrado en su 
proceso de desarrollo; esto se lleva a cabo mediante un conjunto de sfmbolos y diagra- 
mas. Cada diagrama tiene fines distintos dentro del proceso de desarrollo. 

El objetivo de este libro es darle, en 24 horas de estudio, las bases sobre el UML. Cada 
hora le presentara ejemplos para mejorar la comprension e incluira ejercicios que le per- 
mitiran practicar sus recien adquiridos conocimientos. 

Dividf este libro en tres partes: la primera parte le da un panorama del UML y le explica 
la orientacion a objetos, misma que conforma los conceptos fundamentales de la diagra- 
macion de objetos y clases. Examinaremos los casos de uso (una estructura para mostrar 
la forma en que un sistema lucira ante el usuario, para luego mostrar como hacer dia- 
gramas de esta estructura). Las horas restantes de la primera parte le permitiran trabajar 
con el resto de los diagramas UML. 

La segunda parte le muestra una metodologfa simplificada para el desarrollo, enriquecida 
con el estudio de un caso ficticio. Asf, las horas de la segunda parte le mostraran la 
forma en que el UML se adapta al contexto de un proyecto de desarrollo. Vera la forma 
en que los elementos del UML funcionan en conjunto para modelar un sistema. 

Por ultimo, en la tercera parte aplicaremos el UML para disenar patrones y sistemas 
incrustados, y examinaremos su campo de aplicacion en dos areas mas. 

Existen diversos fabricantes que cuentan con paquetes que le permitiran generar diagra- 
mas UML y coordinarlos en un modelo. Los mas notables son Rational Rose y SELECT 
Enterprise, aunque cabe mencionar que Visual UML es otro digno contendiente. 
Microsoft esta autorizado para utilizar la tecnologfa de Rational y asf comercializa Visual 
Modeler, un subconjunto de Rational Rose. No obstante, en este libro todo lo que necesi- 
tara sera un lapiz y papel para dibujar los diagramas y una sana curiosidad respecto al 
estado actual del diseno de sistemas. 



jlniciemos! 




Convenciones utilizadas en este libro 



En los diagramas incluidos en este libro no utilizamos vocales con acento, ni la letra ene. 
Esto debido a que el alfabeto ingles, de donde procede la mayorfa de los lenguajes de 
programacion, no los incluye y el empleo de esos caracteres en sus diagramas podria 
acarrearle probiemas tanto en el UML como en el lenguaje de programacion que piense 




Una Nota presenta interesantes secciones de informacion relacionadas con el 
tema que se trate. 



Termino Nuevo 



El icono Termino Nuevo resalta las definiciones de vocablos nuevos y esen- 
ciales. El vocablo, en si, aparecera en cursiva . 
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Hora 



Introduccion al UML 

El UML (Lenguaje Unificado de Modelado) es una de las herramientas mas 
emocionantes en el mundo actual del desarrollo de sistemas. Esto se debe a 
que permite a los creadores de sistemas generar disenos que capturen sus 
ideas en una forma convencional y facil de comprender para comunicarlas a 
otras personas. 

En esta hora se trataran los siguientes temas: 

• Por que es necesario el UML 

• La concepcion del UML 

• Diagramas del UML 

• Para que tantos diagramas 



En el contexto de este libro considere a un sistema como una 

combination de software y hardware que da una solution a un 

problema de negocios. El desarrollo de sistemas es la creacibn de un programa 
para un cliente, este ultimo es quien tiene el problema que debe ser resuelto. Un 
analista es el que documenta el problema del cliente y lo comunica a los desarro- 
Uadores, que son los programadores que generarSn el programa que resolver^ el 
problema y lo distribuir£n en equipos de computacibn. 



Termino Nuevo 




La comunicacion de la idea es de suma importancia. Antes del advenimiento del UML, el 
desarrollo de sistemas era, con frecuencia, una propuesta al azar. Los analistas de sis- 
temas intentaban evaluar los requerimientos de sus clientes, generar un analisis de 
requerimientos en algun tipo de notation que ellos mismos comprendieran (aunque el 
cliente no lo comprendiera), dar tal analisis a uno o varios programadores y esperar que 
el producto final cumpliese con lo que el cliente deseaba. 

Dado que el desarrollo de sistemas es una actividad humana, hay muchas posibilidades 
de cometer errores en cualquier etapa del proceso, por ejemplo, el analista pudo haber 
malentendido al cliente, es decir, probablemente produjo un documento que el cliente no 
pudo comprender. Tal vez ese documento tampoco fue comprendido por los programa- 
dores quienes, por ende, pudieron generar un programa dificil de utilizar y no generar 
una solucion al problema original del cliente. 

^Alguien se preguntara por que muchos de los sistemas en uso son ineficientes, engorro- 
sos y difitiles de utilizar? 

Por que es necesario el UML 

En los principios de la computation, los programadores no realizaban analisis muy pro- 
fundos sobre el problema por resolver. Si acaso, garabateaban algo en una servilleta. 
Con frecuencia comenzaban a escribir el programa desde el principio, y el codigo nece- 
sario se escribia conforme se requerfa. Aunque anteriormente esto agregaba un aura de 
aventura y atrevimiento al proceso, en la actualidad es inapropiado en los negocios de alto 
riesgo. 

Hoy en dia, es necesario contar con un plan bien analizado. Un cliente tiene que compren- 
der que es lo que hara un equipo de desarrolladores; ademas tiene que ser capaz de 
senalar cambios si no se han captado claramente sus necesidades (o si cambia de opinion 
durante el proceso). A su vez, el desarrollo es un esfuerzo orientado a equipos, por lo que 
cada uno de sus miembros tiene que saber que lugar toma su trabajo en la solucion final 
(asf como saber cual es la solucion en general). 

Conforme aumenta la complejidad del mundo, los sistemas informaticos tambien deberan 
crecer en complejidad. En ellos se encuentran diversas piezas de hardware y software que 
se comunican a grandes distancias mediante una red, misma que esta vinculada a bases de 
datos que, a su vez, contienen enormes cantidades de information. Si desea crear sistemas 
que lo involucren con este nuevo milenio ^como manejara tanta complejidad? 

La clave esta en organizar el proceso de diseho de tal forma que los analistas, clientes, 
desarrolladores y otras personas involucradas en el desarrollo del sistema lo comprendan 
y convengan con el. El UML proporciona tal organization. 

Un arquitecto no podna crear una compleja estructura como lo es un edificio de oficinas 
sin crear primero un anteproyecto detallado; asimismo usted tampoco podna generar un 
complejo sistema en un edificio de oficinas sin crear un plan de diseho detallado. La idea 




es que asi como un arquitecto le muestra un anteproyecto a la persona que lo contrato, 
usted debera mostrarle su plan de diseno al cliente. Tal plan de diseno debe ser el resul- 
tado de un cuidadoso analisis de las necesidades del cliente. 

Otra caractenstica del desarrollo de sistemas contemporaneo es reducir el periodo de 
desarrollo. Cuando los plazos se encuentran muy cerca uno del otro es absolutamente 
necesario contar con un diseno solido. 

Hay otro aspecto de la vida modema que demanda un diseno solido: las adquisiciones 
corporativas. Cuando una empresa adquiere a otra, la nueva organizacion debe tener la 
posibilidad de modificar aspectos importantes de un proyecto de desarrollo que este en 
progreso (la herramienta de desarrollo, el lenguaje de codificacion, y otras cosas). Un 
anteproyecto bien disenado facilitara la conversion. Si el diseno es solido, un cambio en 
la implementacion procedera sin problemas. 

La necesidad de disenos solidos ha traido consigo la creacion de una notacion de diseno 
que los analistas, desarrolladores y clientes acepten como pauta (tal como la notacion en 
los diagramas esquematicos sirve como pauta para los trabajadores especializados en 
electronica). El UML es esa misma notacion. 

La concepcion del UML 

El UML es la creacion de Grady Booch, James Rumbaugh e Ivar Jacobson. Estos 
caballeros, apodados recientemente “Los tres amigos”, trabajaban en empresas distintas 
durante la decada de los anos ochenta y principios de los noventa y cada uno diseno su 
propia metodologfa para el analisis y diseno orientado a objetos. Sus metodologias pre- 
dominaron sobre las de sus competidores. A mediados de los anos noventa empezaron a 
intercambiar ideas entre si y decidieron desarrollar su trabajo en conjunto. 




Las horas 2, "Orientacion a objetos", y 4, "Uso de relaciones", tratan de la 
orientacion a objetos. Los conceptos de orientacion a objetos tienen un papel 
fundamental en el desarrollo de este libro. 



En 1994 Rumbaugh ingreso a Rational Software Corporation, donde ya trabajaba Booch. 
Jacobson ingreso a Rational un ano despues; el resto, como dicen, es historia. 

Los anteproyectos del UML empezaron a circular en la industria del software y las reac- 
ciones resultantes trajeron consigo considerables modificaciones. Conforme diversos cor- 
porativos vieron que el UML era util a sus propositos, se conformo un consorcio del 
UML. Entre los miembros se encuentran DEC, Hewlett-Packard, Intellicorp, Microsoft, 
Oracle, Texas Instruments y Rational. En 1997 el consorcio produjo la version 1.0 del 
UML y lo puso a consideration del OMG (Grupo de administration de objetos) como 
respuesta a su propuesta para un lenguaje de modelado estandar. 





El consorcio aumento y genero la version 1.1, misma que se puso nuevamente a consi- 
deration del OMG. El grupo adopto esta version a finales de 1997. El OMG se encargo de 
la conservation del UML y produjo otras dos revisiones en 1998. El UML ha llegado a 
ser el estandar de facto en la industria del software, y su evolution continua. 

Diagramas del UML 

El UML esta compuesto por diversos elementos graficos que se combinan para confor- 
mar diagramas. Debido a que el UML es un lenguaje, cuenta con reglas para combinar 
tales elementos. En lugar de indicarle a usted cuales son los elementos y las reglas, 
veamos directamente los diagramas ya que los utilizara para hacer el analisis del sistema. 




Este enfoque es similar a aprender un idioma extranjero mediante el uso del 
mismo, en lugar de aprender sus reglas gramaticales y la conjugacion de sus 
verbos. Despues de un tiempo de hablar otro idioma se le facilitara la conju- 
gacion de verbos y la comprension de las reglas gramaticales. 
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La finalidad de los diagramas es presentar diversas perspectivas de un sistema, 
a las cuales se les conoce como modelo. El modelo UML de un sistema es 
similar a un modelo a escala de un edificio junto con la interpretation del artista del edi- 
ficio. Es importante destacar que un modelo UML describe lo que supuestamente hara 
un sistema, pero no dice como implementar dicho sistema. 



A continuation se describiran brevemente los diagramas mas comunes del UML y los 
conceptos que representan. Posteriormente, en la parte I vera cada uno de los diagra- 
mas con mayor detenimiento. Recuerde que es posible generar hfbridos de estos dia- 
gramas y que el UML otorga formas de organizarlos y extenderlos. 



Diagrama de dases 

Piense en las cosas que le rodean (una idea demasiado amplia, pero jintentelo de 
cualquier forma!). Es probable que muchas de esas cosas tengan atributos (propiedades) 
y que realicen determinadas acciones. Podrfamos imaginar cada una de esas acciones 
como un conjunto de tareas. 

Tambien se encontrara con que las cosas naturalmente se albergan en cate- 
gories (automoviles, mobiliario, lavadoras...). A tales categorfas las llamare- 
mos clases. Una clase es una categorfa o grupo de cosas que tienen atributos y acciones 
similares. He aquf un ejemplo: cualquier cosa dentro de la clase Lavadoras tiene atribu- 
tos como son la marca, el modelo, el numero de serie y la capacidad. Entre las acciones 
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de las cosas de esta clase se encuentran: “agregar ropa”, “agregar detergente”, “activarse” 
y “sacar ropa”. 

La figura 1 . 1 le muestra un ejemplo de la notation del UML que captura los atributos y 
acciones de una lavadora. Un rectangulo es el simbolo que representa a la clase, y se 
divide en tres areas. El area superior contiene el nombre, el area central contiene los 
atributos, y el area inferior las acciones. Un diagrama de clases esta formado por varios 
rectangulos de este tipo conectados por lineas que muestran la manera en que las clases 
se relacionan entre si. 



Figura 1.1 

El simbolo UML 
de una clase. 



Lavadora 

marca 

modelo 

numero de serie 
capacidad 

agregar ropa() 
agregar detergenteQ 
sacar ropa() 



^Que objetivo tiene pensar en las clases, asf como sus atributos y acciones? Para interac- 
tuar con nuestro complejo mundo, la mayorfa del software modemo Simula algun aspecto 
del mundo. Decadas de experiencia sugieren que es mas sencillo desarrollar aplicaciones 
que simulen algun aspecto del mundo cuando el software representa clases de cosas 
reales. Los diagramas de clases facilitan las representaciones a partir de las cuales los 
desarrolladores podran trabajar. 

A su vez, los diagramas de clases colaboran en lo referente al analisis. Permiten al 
analista hablarle a los clientes en su propia terminologia, lo cual hace posible que los 
clientes indiquen importantes detalles de los problemas que requieren ser resueltos. 

Diagrama de objetos 

Un objeto es una instancia de clase (una entidad que tiene valores especifi- 
cos de los atributos y acciones). Su lavadora, por ejemplo, podrfa tener la 
marca Laundatorium, el modelo Washmeister, el numero de serie GL57774 y una 
capacidad de 7 Kg. 

La figura 1.2 le muestra la forma en que el UML representa a un objeto. Vea que el sim- 
bolo es un rectangulo, como en una clase, pero el nombre esta subrayado. El nombre de 
la instancia especifica se encuentra a la izquierda de los dos puntos (:), y el nombre de la 
clase a la derecha. 
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Figura 1.2 

El si'mbolo UML del 
objeto . 



Mi Lavadora: Lavadora 



Diagrama de casos de uso 

Un caso de uso es una description de las acciones de un sistema desde el 
punto de vista del usuario. Para los desarrolladores del sistema, esta es una 
herramienta valiosa, ya que es una tecnica de aciertos y errores para obtener los reque- 
rimientos del sistema desde el punto de vista del usuario. Esto es importante si la finali- 
dad es crear un sistema que pueda ser utilizado por la gente en general (no solo por 
expertos en computacion). 

Posteriormente trataremos este tema con mayor detalle; por ahora, le mostrare un ejem- 
plo sencillo. Usted utiliza una lavadora, obviamente, para lavar su ropa. La figura 1.3 le 
muestra como representaria esto en un diagrama de casos de uso UML. 
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Figura 1.3 

Diagrama de casos 
de uso UML 




■^^^Tavar ropa 




Usuario de la lavadora 
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A la figura correspondiente al Usuario de la lavadora se le conoce como actor. 
La elipse representa el caso de uso. Vea que el actor (la entidad que inicia el 
caso de uso) puede ser una persona u otro sistema. 



Diagrama de estados 

En cualquier momento, un objeto se encuentra en un estado en particular. Una persona 
puede ser recien nacida, infante, adolescente, joven o adulta. Un elevador se movera 
hacia arriba, estara en estado de reposo o se movera hacia abajo. Una lavadora podra 
estar en la fase de remojo, lavado, enjuague, centrifugado o apagada. 

El diagrama de estados UML, que aparece en la figura 1 .4, captura esta pequena reali- 
dad. La figura muestra las transiciones de la lavadora de un estado al otro. 

El simbolo que esta en la parte superior de la figura representa el estado inicial y el de la 
parte inferior el estado final. 






Figura 1.4 

Diagrama de estados 
UML 




Diagrama de secuencias 

Los diagramas de clases y los de objeto representan information estatica. No obstante, 
en un sistema funcional los objetos interactuan entre si, y tales interacciones suceden 
con el tiempo. El diagrama de secuencias UML muestra la mecanica de la interaction con 
base en tiempos. 

Continuando con el ejemplo de la lavadora, entre los componentes de la lavadora 
se encuentran: una manguera de agua (para obtener agua fresca), un tambor (donde se 
coloca la ropa) y un sistema de drenaje. Por supuesto, estos tambien son objetos (como 
vera, un objeto puede estar conformado por otros objetos). 

^Que sucedera cuando invoque al caso de uso Lavar ropa? Si damos por hecho que com- 
pleto las operaciones “agregar ropa”, “agregar detergente” y “activar”, la secuencia seria 
mas o menos asi: 

L El agua empezara a llenar el tambor mediante una manguera. 

2. El tambor permanecera inactivo durante cinco minutos. 

3. La manguera dejara de abastecer agua. 

4. El tambor girara de un lado a otro durante quince minutos. 

5. El agua jabonosa saldra por el drenaje. 

6. Comenzara nuevamente el abastecimiento de agua. 

7. El tambor continuara girando. 






8. El abastecimiento de agua se detendra. 

9. El agua del enjuague saldra por el drenaje. 

10. El tambor girara en una sola direction y se incremental su velocidad por cinco 
minutos. 

11. El tambor dejara de girar y el proceso de lavado habra finalizado. 

La figura 1.5 presenta un diagrama de secuencias que captura las interacciones que se 
realizan a traves del tiempo entre el abastecimiento de agua, el tambor y el drenaje (re- 
presentados como rectangulos en la parte superior del diagrama). En este diagrama el 
tiempo se da de arriba hacia abajo. 



Figura 1.5 

Diagrama de 
secuencias UML. 




Por cierto, volviendo a las ideas acerca de los estados, podriamos caracterizar los pasos 1 
y 2 como el estado de remojo, 3 y 4 como el estado de lavado, 5 a 7 como el estado de 
enjuague y del 8 al 10 como el estado de centrifugado. 

Diagrama de actividades 

Las actividades que ocurren dentro de un caso de uso o dentro del comportamiento de un 
objeto se dan, normalmente, en secuencia, como en los once pasos de la section anterior. 
La figura 1.6 muestra la forma en que el diagrama de actividades UML representa los 
pasos del 4 al 6 de tal secuencia. 





Figura 1.6 



Girar el tambor de un lado a otro 15 minutos 



Diagrama de 
actividades UML. 




Diagrama de colaboraciones 

Los elementos de un sistema trabajan en conjunto para cumplir con los objetivos del sis- 
tema, y un lenguaje de modelado debera contar con una forma de representar esto. El 
diagrama de colaboraciones UML, disenado con este fin, se muestra en la figura 1 .7. 
Este ejemplo agrega un cronometro intemo al conjunto de clases que constituyen a una 
lavadora. Luego de cierto tiempo, el cronometro detendra el flujo de agua y el tambor 
comenzara a girar de un lado a otro. 



Figura 1.7 

Diagrama de 
colaboraciones UML. 




Diagrama de componentes 

Este diagrama y el siguiente dejaran el mundo de las lavadoras, dado que estan mtima- 
mente ligados con los sistemas informaticos. 

El modemo desarrollo de software se realiza mediante componentes, lo que es particular- 
mente importante en los procesos de desarrollo en equipo. Sin extenderme mucho en este 
punto le mostrare, en la figura 1.8, la manera en que el UML representa un componente 
de software. 



Figura 1 .8 

Diagrama de 
componentes UML. 



Componente 








Diagrama de distribution 

El diagrama de distribucion UML muestra la arquitectura ffsica de un sistema infor- 
matico. Puede representar los equipos y dispositivos, mostrar sus interconexiones y el 
software que se encontrara en cada maquina. Cada computadora esta representada por un 
cubo y las interacciones entre las computadoras estan representadas por lfneas que 
conectan a los cubos. La figura 1.9 presenta un ejemplo. 



Figura 1.9 

Diagrama de 
distribucion UML. 




Otras caracteristicas 

Anteriormente, mencione que el UML proporciona caractensticas que le permiten orga- 
nizar y extender los diagramas. 

Paquetes 

En algunas ocasiones se encontrar£ con la necesidad de organizar los elemen- 
ts de un diagrama en un grupo. Tal vez quiera mostrar que ciertas clases o 
componentes son parte de un subsistema en particular. Para ello, los agrupara en un 
paquete , que se representara por una carpeta tabular, como se muestra en la figura 1.10. 
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Figura 1.10 

El paquete UML le 
permit e agrupar los 
elementos de un 
diagrama. 



Paquete 1 




Clase 1 










Clase 2 


Clase 3 


1 






Notas 
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Es frecuente que alguna parte del diagrama no presente una clara explicacion 
del porque esta alii o la manera en que trabaja. Cuando este sea el caso, la 
nota UML sera util. Imagine a una nota como el equivalente grafico de un papel adhe- 
sivo. La nota es un rectangulo con una esquina doblada, y dentro del rectangulo se 
coloca la explicacion. Usted adjunta la nota al elemento del diagrama conectandolos 
mediante una lmea discontinua. 



Figura 1.11 

En cualquier 
diagrama, podra 
agregar comentarios 
aclaratorios mediante 
una nota. 



Texto explicativo 
respecto a 



icativo | 

i la Clase 1 




Estereotipos 

El UML otorga varios elementos de utilidad, pero no es un conjunto minu- 
cioso de ellos. De vez en cuando disenara un sistema que requiera algunos 
elementos hechos a la medida. Los estereotipos o clises le permiten tomar elementos 
propios del UML y convertirlos en otros. Es como comprar un traje del mostrador y 
modificarlo para que se ajuste a sus medidas (contrario a confeccionarse uno completa- 
mente nuevo). Imagine a un estereotipo como este tipo de alteration. Lo representara 
como un nombre entre dos pares de parentesis angulares y despues los aplicara correcta- 
mente. 



Termino Nuevo 



Termino Nuevo 



El concepto de una interfaz provee un buen ejemplo. Una interfaz es una 
clase que realiza operaciones y que no tiene atributos, es un conjunto de 
acciones que tal vez quiera utilizar una y otra vez en su modelo. En lugar de inventar 
un nuevo elemento para representar una interfaz, podra utilizar el simbolo de una clase 
con «Interfaz» situada justo sobre el nombre de la clase, como se muestra en la figura 
1 . 12 . 



Figura 1.12 

Un estereotipo le 

«lnterfaz» 

permite crear nuevos Clase 1 

elementos a partir de 

otros existentes. 







Para que tantos diagramas 

Como puede ver, los diagramas del UML le permiten examinar un sistema desde distin- 
tos puntos de vista. Es importante recalcar que en un modelo UML no es necesario que 
aparezcan todos los diagramas. De hecho, la mayorfa de los modelos UML contienen un 
subconjunto de los diagramas que he indicado. 

^Por que es necesario contar con diferentes perspectivas de un sistema? Por lo 
general, un sistema cuenta con diversas personas implicadas las cuales tienen 
enfoques particulares en diversos aspectos del sistema. Volvamos al ejemplo de la 
lavadora. Si disenara el motor de una lavadora, tendria una perspectiva del sistema; si 
escribiera las instrucciones de operacidn, tendria otra perspectiva. Si disenara la forma 
general de la lavadora verfa al sistema desde una perspectiva totalmente distinta a si tan 
solo tratara de lavar su ropa. 

El escrupuloso diseno de un sistema involucra todas las posibles perspectivas, y el dia- 
grama UML le da una forma de incorporar una perspectiva en particular. El objetivo es 
satisfacer a cada persona implicada. 

Resumen 

El desarrollo de sistemas es una actividad humana. Sin un sistema de notacidn facil de 
comprender, el proceso de desarrollo tiene una gran cantidad de errores. 

El UML es un sistema de notation que se ha convertido en estandar en el mundo del 
desarrollo de sistemas. Es el resultado del trabajo hecho por Grady Booch, James 
Rumbaugh e Ivar Jacobson. El UML esta constituido por un conjunto de diagramas, y 
proporciona un estandar que permite al analista de sistemas generar un anteproyecto de 
varias facetas que sean comprensibles para los clientes, desarrolladores y todos aquellos 
que esten involucrados en el proceso de desarrollo. Es necesario contar con todos esos 
diagramas dado que cada uno se dirige a cada tipo de persona implicada en el sistema. 

Un modelo UML indica que es lo que supuestamente hara el sistema, mas no como lo 
hara. 

Preguntas y respuestas 

P He visto que se refiere al Lenguaje Unificado de Modelado como “UML” y 
como “el UML”. <,Cual es el correcto? 

R Los creadores del lenguaje prefieren el uso de “el UML”. 

P Ha indicado que el UML es adecuado para los analistas. No obstante, el 
diagrama de distribution no parece ser algo muy util en la fase de analisis 
en el desarrollo de un sistema. £No seria mas apropiado para una fase 
posterior? 



Termino Nuevo 




R En realidad nunca sera demasiado pronto para empezar a pensar en la distribution 
(u otras cuestiones que, tradicionalmente, se dejan para fases posteriores del desa- 
rrollo). Aunque es cierto que el analista se interesa por hablar con los clientes y 
usuarios, en las fases tempranas del proceso el analista deberfa pensar en los 
equipos y componentes que constituirfan el hardware del sistema. En algunas oca- 
siones, el cliente dicta esto; en otras, el cliente desea una recomendacion del 
equipo de desarrollo. Ciertamente, un arquitecto de sistemas encontrara util al dia- 
grama de distribucion. 

P Ha mencionado que es posible hacer diagramas hfbridos. ^UML, perdon, el 
UML, impone limitaciones respecto a los elementos que podra combinar en un 
diagrama? 

R No. El UML no establece lfmites, no obstante, con frecuencia se da el caso de que 
un diagrama contenga un tipo de elemento. Podra colocar simbolos de clases en un 
diagrama de distribucion, pero ello no sera muy util. 



Taller 

Ya se ha iniciado en el UML. Ahora debera reafirmar su conocimiento de esta gran 
herramienta al responder algunas preguntas y realizar los ejercicios. Las respuestas 
apareceran en el Apendice A, “Respuestas a los cuestionarios”. 

Cuestionario 

1. ^Porque es necesario contar con diversos diagramas en el modelo de un sistema? 

2. ^Cuales diagramas le dan una perspectiva estatica de un sistema? 

3. ^Cuales diagramas le dan una perspectiva dinamica de un sistema (esto es, mues- 
tran el cambio progresivo)? 

Ejercicios 

1. Suponga que creara un sistema informatico que jugara ajedrez con un usuario. 
^Cuales diagramas UML serfan utiles para disenar el sistema? ^Por que? 

2. Para el sistema del ejercicio que ha completado, liste las preguntas que formulana 
a un usuario potencial y por que las harfa. 
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Orientation 
a objetos 

Es fundamental que comprenda todo lo relacionado a la orientacidn a 
objetos para el proceso que realizara; especfficamente, es importante que 
conozca algunos conceptos sobre la orientacion a objetos. 

En esta hora se trataran los siguientes temas: 

• Abstraction 

• Herencia 

• Polimorfismo 

• Encapsulamiento o encapsulation 

• Envio de mensajes 

• Asociaciones 

• Agregacion 

La orientacion a objetos ha tornado por asalto y en forma legftima al mundo 
del software. Como medio para la generation de programas, tiene varias ven- 
tajas. Fomenta una metodologia basada en componentes para el desarrollo 



de software, de manera que primero se genera un sistema mediante un conjunto de obje- 
tos, luego podra ampliar el sistema agregandole funcionalidad a los componentes que ya 
habfa generado o agregandole nuevos componentes, y finalmente podra volver a utilizar 
los objetos que genero para el sistema cuando cree uno nuevo, con lo cual reducira sus- 
tancialmente el tiempo de desarrollo de un sistema. 

La orientacion a objetos es tan importante para el diseno de software que el OMG 
(Grupo de administration de objetos), una corporation no lucrativa que establece 
las normas para el desarrollo orientado a objetos, predice que los ingresos obtenidos 
por el software orientado a objetos seran de 3 millardos de dolares en los siguientes 
tres a cinco anos. El UML influye en esto al permitirle generar modelos de objetos 
faciles de usar y comprender para que los desarrolladores puedan convertirlos 
en software. 

La orientacidn a objetos es un paradigma (un paradigma que depende de ciertos princi- 
pios fundamentales). En esta hora comprendera dichos principios y verS que es lo que 
hace funcionar a los objetos y como utilizarlos en el analisis y diseno. En la siguiente 
hora, empezara a aplicar el UML a tales principios. 

Objetos, objetos por doquier 

Los objetos concretos y virtuales, estan a nuestro alrededor, ellos conforman nuestro 
mundo. Como indique en la hora anterior, el software actual Simula al mundo (o un seg- 
mento de el), y los programas, por lo general, imitan a los objetos del mundo. Si com- 
prende algunas cuestiones basicas de los objetos, entendera como se deben mostrar estos 
en las representaciones de software. 

Antes que nada, un objeto es la instancia de una clase (o categona). Usted y 
yo, por ejemplo, somos instancias de la clase Persona. Un objeto cuenta con 
una estructura, es decir atributos (propiedades) y acciones. Las acciones son todas las 
actividades que el objeto es capaz de realizar. Los atributos y acciones, en conjunto, se 
conocen como caracteristicas o rasgos. 

Como objetos de la clase Persona, usted y yo contamos con los siguientes atributos: 
altura, peso y edad (puede imaginar muchos mas). Tambien realizamos las siguientes 
tareas: comer, dormir, leer, escribir, hablar, trabajar, etcetera. Si tuvieramos que crear 
un sistema que manejara information acerca de las personas (como una nomina o un 
sistema para el departamento de recursos humanos), serfa muy probable que incorpo- 
raramos algunos de sus atributos y acciones en nuestro software. 

En el mundo de la orientacion a objetos, una clase tiene otro proposito ademas de la 
categorizacion. En realidad es una plantilla para fabricar objetos. Imagmelo como un 
molde de galletas que produce muchas galletas (algunos alegarfan que esto es lo mismo 
que la categorizacion, pero evitemos dicho debate). 
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Regresemos al ejemplo de la lavadora. Si en la clase Lavadora se indica la marca, el 
modelo, el numero de sene y la capacidad (junto con las acciones de agregar ropa, 
agregar detergente y sacar ropa), tendra un mecanismo para fabricar nuevas instancias 
a partir de su clase; es decir, podra crear nuevos objetos (vea la figura 2.1). 




En la hora 3, "Uso de la orientacion a objetos", vera que los nombres de las 
clases, como lavadora, se escribiran como Lavadora, y si constara de dos pala- 
bras se escribirfa como Lavadoralndustrial, y las caracterfsticas como numero 
de serie se escribiran como numeroSerie. 



Esto es particularmente importante en el desarrollo de software orientado a objetos. 
Aunque este libro no se enfoca a la programacidn, le ayudara a comprender la orien- 
tacion a objetos si sabe que las clases en los programas orientados a objetos pueden 
crear nuevas instancias. 



Figura 2.1 

La clase Lavadora 
( modelo original ) 
es una plantilla 
para generar 
nuevas instancias 
de Lav adorns. 



Lavadora 



marca 

modelo 

numeroSerie 

capacidad 



agregarRopa() 

agregarDetergente() 

sacarRopa() 



Es importante que recuerde que el proposito de la orientacion a objetos es desarrollar 
software que refleje particularmente (es decir, que modele) un esquema del mundo. 

Entre mas atributos y acciones tome en cuenta, mayor sera la similitud de su modelo con 
la realidad. En el ejemplo de la lavadora, tendra un modelo mas exacto si incluye los 
siguientes atributos: volumen del tambor, cronometro intemo, trampa, motor y velocidad 
del motor. Podrfa hacerlo mas preciso si incluye las acciones de agregar blanqueador, 
cronometrar el remojo, cronometrar el lavado, cronometrar el enjuague y cronometrar 
el centrifugado (vea la figura 2.2). 






Figura 2.2 

La adicion de 
atributos y acciones 
al modelo lo acerca 
a la realidad. 



Lavadora 



marca 

modelo 

numeroSerie 

capacidad 

volumenTambor 

cronometrolnterno 

trampa 

motor 

velocidadMotor 



agregarRopa() 

agregarDetergente() 

sacarRropa() 

agregarBlanqueador() 

cronometrarRemojo() 

cronometrarLavado() 

cronometrarEnjuague() 

cronometrarCentrifugado() 



Algunos conceptos 

La orientation a objetos se refiere a algo mas que tan solo atributos y acciones; tambien 
considera otros aspectos. Dichos aspectos se conocen como abstraction , herencia , 
polimorfismo y encapsulamiento o encapsulation. Otros aspectos importantes de la 
orientation a objetos son: el envi'o de mensajes , las asociaciones y la agregacidn. 
Examinemos cada uno de estos conceptos. 



Abstraction 
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La abstraction se refiere a quitar las propiedades y acciones de un objeto 
para dejar solo aquellas que sean necesarias. ^Que significa esto ultimo? 



Diferentes tipos de problemas requieren distintas cantidades de information, aun si estos 
problemas pertenecen a un area en comun. En la segunda fase de la creation de la clase 
Lavadora, se podrfan agregar mas atributos y acciones que en la primera fase. £ Vale la 
pena? 

Valdrfa la pena si usted pertenece al equipo de desarrollo que generara finalmente la 
aplicacion que simule con exactitud lo que hace una lavadora. Un programa de este tipo 
(que podrfa ser muy util para los ingenieros de diseno que actualmente esten trabajando 
en el diseno de una lavadora) debera ser tan completo que permita obtener predicciones 
exactas respecto a lo que ocurrina cuando se fabrique la lavadora, funcione a toda su 
capacidad y lave la ropa. De hecho, para este caso podra quitar el atributo del numero de 
serie, dado que posiblemente no sera de mucha ayuda. 



Por otra parte, si va a generar un software que haga un seguimiento de las transacciones 
en una lavanderfa que cuente con diversas lavadoras, posiblemente no valdra la pena. 

En este programa no necesitara todos los atributos detallados y operaciones del parrafo 
anterior, no obstante, quiza necesite incluir el numero de serie de cada objeto Lavadora. 





En cualquier caso, con lo que se quedara luego de tomar su decision respecto a lo que 
incluira o desechara, sera una abstraction de una lavadora. 



Herencia 
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Como ya se menciono anteriormente, una clase es una categona de objetos 
(y en el mundo del software, una plantilla sirve para crear otros objetos). Un 
objeto es una instancia de una clase. Esta idea tiene una consecuencia importante: como 
instancia de una clase, un objeto tiene todas las caracteristicas de la clase de la que pro- 
viene. A esto se le conoce como herencia. No importa que atributos y acciones decida 
usar de la clase Lavadora, cada objeto de la clase heredard dichos atributos y operaciones. 

Un objeto no solo hereda de una clase, sino que una clase tambi^n puede heredar de otra. 
Las lavadoras, refrigeradores, homos de microondas, tostadores, lavaplatos, radios, 
licuadoras y planchas son clases y forman parte de una clase mas generica llamada: 
Electrodomesticos. Un electrodomestico cuenta con los atributos de interruptor y cable 
electrico, y las operaciones de encendido y apagado. Cada una de las clases Electrodo- 
mestico heredara los mismos atributos; por ello, si sabe que algo es un electrodomestico, 
de inmediato sabra que cuenta con los atributos y acciones de la clase Electrodomestico. 
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Otra forma de explicarlo es que la lavadora, refrigerador, homo de microon- 
das y cosas por el estilo son subclases de la clase Electrodomestico. Podemos 
decir que la clase Electrodomestico es una superclase de todas las demas. La figura 2.3 
le muestra la relation de superclase y subclase. 



Figura 2.3 

Los electrodomesticos 
heredan los atributos 
y acciones de la clase 
Electrodomestico. 

Cada electrodomestico 
es una subclase de 
la clase Electro- 
domestico. La clase 
Electrodomestico es 
una superclase de 
cada subclase. 







La herencia no tiene por que terminar aqui. Por ejemplo, Electrodomestico es una sub- 
clase de Articulos del hogar, como le muestra la figura 2.4. Otra de las subclases de 
Articulos del hogar podria ser Mobiliario, que tendra sus propias subclases. 



Figura 2.4 

Las superclases 
tambien pueden ser 
subclases, y heredar 
de otras superclases. 




Polimorfismo 

En ocasiones una operacion tiene el mismo nombre en diferentes clases. Por 
ejemplo, podra abrir una puerta, una ventana, un periodico, un regalo o una 
cuenta de banco, en cada uno de estos casos, realizard una operacidn diferente. En la 
orientacidn a objetos, cada clase “sabe” como realizar tal operacidn. Esto es el polimor- 
fismo (vea la figura 2.5). 
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Figura 2.5 

En el polimorfismo , 
una operacion puede 
tener el mismo nombre 
en diversas clases, 
y funcionar distinto 
en cada una. 






En primera instancia, parecerfa que este concepto es mas importante para los desarrolla- 
dores de software que para los modeladores, ya que los desarrolladores tienen que crear el 
software que implemente tales metodos en los programas de computation, y deben estar 
conscientes de diferencias importantes entre las operaciones que pudieran tener el mismo 
nombre. Y podran generar clases de software que “sepan” lo que se supone que haran. 

No obstante, el polimorfismo tambien es importante para los modeladores ya que les 
permite hablar con el cliente (quien esta familiarizado con la section del mundo que sera 
modelada) en las propias palabras y terminologia del cliente. En ocasiones, las palabras 
y terminologia del cliente nos conducen a palabras de accion (como “abrir”) que pueden 





tener mas de un significado. El polimorfismo permite al modelador mantener tal termi- 
nologia sin tener que crear palabras artificiales para sustentar una unicidad innecesaria 
de los terminos. 



Encapsulamiento 

En cierto comercial televisivo, dos personas discuten acerca de todo el dinero que ahorra- 
rfan si marcaran un prefijo telefonico en particular antes de hacer una llamada de larga 
distancia. 
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Uno de ellos pregunta con incredulidad: “^Como funciona?” 

Y el otro responde: “^Como hacen que las rosetas de maiz estallen? quien le importa?” 

La esencia del encapsulamiento (o encapsulation) es que cuando un objeto trae 
consigo su funcionalidad, esta ultima se oculta (vea la figura 2.6). Por lo gene- 
ral, la mayona de la gente que ve la television no sabe o no se preocupa de la compleji- 
dad electronica que hay detras de la pantalla ni de todas las operaciones que tienen que 
ocurrir para mostrar una imagen en la pantalla. La television hace lo que tiene que hacer 
sin mostramos el proceso necesario para ello y, por suerte, la mayorfa de los electrodomes- 
ticos funcionan asi. 



Figura 2.6 

Los objeto s encapsu- 
late lo que hacen; es 
decir, ocultan la fun- 
cionalidad interna de 
sus operaciones , 
de otros objetos 
y del mundo exterior. 





^Cual es la importancia de esto? En el mundo del software, el encapsulamiento permite 
reducir el potencial de errores que pudieran ocurrir. En un sistema que consta de objetos, 
estos dependen unos de otros en diversas formas. Si uno de ellos falla y los especialistas 
de software tienen que modificarlo de alguna forma, el ocultar sus operaciones de otros 
objetos significara que tal vez no sera necesario modificar los demas objetos. 




En el mundo real, tambien vera la importancia del encapsulamiento en los objetos con 
los que trabaje. Por ejemplo, el monitor de su computadora, en cierto sentido, oculta sus 
operaciones de la CPU, es decir, si algo falla en su monitor, lo reparara o lo reemplazara; 
pero es muy probable que no tenga que reparar o reemplazar la CPU al mismo tiempo 
que el monitor. 

Ya que estamos en el tema, existe un concepto relacionado. Un objeto oculta 
lo que hace a otros objetos y al mundo exterior, por lo cual al encapsula- 
miento tambien se le conoce como ocultamiento de la informacion. Pero un objeto 
tiene que presentar un “rostro” al mundo exterior para poder iniciar sus operaciones. 

Por ejemplo, la television tiene diversos botones y perillas en si misma o en el control 
remoto. Una lavadora tiene diversas perillas que le permiten establecer los niveles de 
temperatura y agua. Los botones y perillas de la television y de la lavadora se conocen 
como interfaces . 

Envfo de mensajes 

Mencione que en un sistema los objetos trabajan en conjunto. Esto se logra mediante 
el envio de mensajes entre ellos. Un objeto envia a otro un mensaje para realizar una 
operacion, y el objeto receptor ejecutara la operacion. 

Una television y su control remoto pueden ser un ejemplo muy intuitivo del mundo 
que nos rodea. Cuando desea ver un programa de television, busca el control remoto, 
se sienta en su silla favorita y presiona el boton de encendido. Que ocurre? El control 
remoto le envia, literalmente, un mensaje al televisor para que se encienda. El televisor 
recibe el mensaje, lo identifica como una petition para encenderse y asi lo hace. Cuando 
desea ver otro canal, presiona el boton correspondiente del control remoto, mismo que 
envia otro mensaje a la television (cambiar de canal). El control remoto tambien puede 
comunicar otros mensajes como ajustar el volumen, silenciar y activar los subtftulos. 

Volvamos a las interfaces. Muchas de las cosas que hace mediante el control remoto, 
tambien las podra hacer si se levanta de la silla, va a la television y presiona los botones 
correspondientes (jalguna vez lo habra hecho ya!). La interfaz que la television le pre- 
senta (el conjunto de botones y perillas) no es, obviamente, la misma que le muestra al 
control remoto (un receptor de rayos infrarrojos). La figura 2.7 le muestra esto. 

Asociaciones 

Otro acontecimiento comun es que los objetos se relacionan entre si de alguna forma. 
Por ejemplo, cuando enciende su televisor, en terminos de orientation a objetos, usted se 
asocia con su televisor. 

La asociacion “encendido” es en una sola direction (una via), esto es, usted enciende la 
television, como se ve en la figura 2.8. No obstante, a menos que vea demasiada tele- 
vision, ella no le devolvera el favor. Hay otras asociaciones que son en dos direcciones, 
como “casamiento”. 
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Figura 2.7 

Ejemplo de un mensaje 
enviado de un objeto 
a otro: el objeto 
“control remoto” 
envia un mensaje al 
objeto “television ” 
para encenderse. 

El objeto “television ” 
recibe el mensaje 
mediante su interfaz, 
un receptor infrarrojo. 




Figura 2.8 

Con frecuencia los 
objetos se relacionan 
entre si' de alguna 
forma . Cuando usted 
enciende su television , 
tendra una asociacion 
en una sola direccion 
con ella. 




En ocasiones, un objeto podrfa asociarse con otro en mas de una forma. Si usted y su 
colaborador son amigos, ello servira de ejemplo. Usted tendrfa una asociacion “es amigo 
de”, asi como “es colaborador de”, como se aprecia en la figura 2.9. 



Figura 2.9 

En ocasiones , los 
objetos pueden 
asociarse en mas 
de una forma. 





Tom 



Bill 




Una clase se puede asociar con mas de una clase distinta. Una persona puede viajar en 
automdvil, pero tambien puede hacerlo en autobus (vea la figura 2.10), 



Figura 2.10 

Una clase puede 
asociarse con mas 
de una clase distinta. 




La multiplicidad (o diversification) es un importante aspecto de las asociacio- 
nes entre objetos. Indica la cantidad de objetos de una clase que se relacionan 
con otro objeto en particular de la clase asociada. Por ejemplo, en un curso escolar, el 
curso se imparte por un solo instructor, en consecuencia, el curso y el instructor estan en 
una asociacion de uno a uno. Sin embargo, en un seminario hay diversos instructores que 
impartiran el curso a lo largo del semestre, por lo tanto, el curso y el instructor tienen 
una asociacion de uno a muchos. 

Podra encontrar todo tipo de multiplicidades si echa una mirada a su alrededor. Una 
bicicleta rueda en dos neumaticos (multiplicidad de uno a dos), un triciclo rueda en tres, 
y un vehfculo de 1 8 ruedas, en 1 8. 

Agregacion 

Vea su computadora: cuenta con un gabinete, un teclado, un raton, un monitor, una 
unidad de CD-ROM, uno o varios discos duros, un modem, una unidad de disquete, una 
impresora y, posiblemente, bocinas. Dentro del gabinete, junto con las citadas unidades 
de disco, tiene una CPU, una tarjeta de video, una de sonido y otros elementos sin los 
que, sin duda, diffcilmente podrfa vivir. 

Su computadora es una agregacion o adicion, otro tipo de asociacion entre 
objetos. Como muchas otras cosas que valdrfan la pena tener, su equipo esta 
constituido de diversos tipos de componentes (vea la figura 2.1 1). Tal vez conozca varios 
ejemplos de agregaciones. 
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Figura 2.11 

Una computadora 
es un ejemplo de 
agregacion: un objeto 
que se conforma de 
una combination 
de diversos tipos de 
objetos . 
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Un tipo de agregacion trae consigo una estrecha relacion entre un objeto 
agregado y sus objetos componentes. A esto se le conoce como composition. 
El punto central de la composicion es que el componente se considera como tal solo 
como parte del objeto compuesto. Por ejemplo: una camisa esta compuesta de cuerpo, 
cuello, mangas, botones, ojales y punos. Suprima la camisa y el cuello sera inutil. 



En ocasiones, un objeto compuesto no tiene el mismo tiempo de vida que sus propios 
componentes. Las hojas de un arbol pueden morir antes que el arbol. Si destruye al 
arbol, tambien las hojas moriran (vea la figura 2.12). 



La agregacion y la composicion son importantes dado que reflejan casos extremada- 
mente comunes, y ello ayuda a que cree modelos que se asemejen considerablemente 
a la realidad. 








Figura 2.12 

En una composition , 
un componente puede 
morir antes que el 
objeto compuesto. 

Si destruye al objeto 
compuesto , destruira 
tambien a los 
componentes. 




La recompensa 

Los objetos y sus asociaciones conforman la columna vertebral de la funcionalidad 
de los sistemas. Para modelarlos, necesitara comprender lo que son las asociaciones. 

Si est£ consciente de los posibles tipos de asociaciones, tendra una amplia gama de 
posibilidades cuando hable con los clientes respecto a sus necesidades, obtendra sus 
requerimientos y creara los modelos de los sistemas que los ayudaran a cumplir con 
sus retos de negocios. 

Lo importante es utilizar los conceptos de la orientacion a objetos para ayu- 
darle a comprender el area de conocimiento de su cliente (su dominio), y 
esclarecer sus puntos de vista al cliente en terminos que el o ella puedan comprender. 

Es alii donde se aplica el UML. En las siguientes tres horas, aprendera a aplicar el UML 
para visualizar los conceptos que ha aprendido durante esta hora. 
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Resumen 

La orientacion a objetos es un paradigma que depende de algunos principios fundamen- 
tales. Un objeto es una instancia de una clase. Una clase es una categorfa generica de 
objetos que tienen los mismos atributos y acciones. Cuando crea un objeto, el area del 
problema en que trabaje determinara cuantos de los atributos y acciones debe tomar 
en cuenta. 

La herencia es un aspecto importante de la orientacion a objetos, un objeto hereda 
los atributos y operaciones de su clase. Una clase tambien puede heredar atributos y 
acciones de otra. 




El polimorfismo es otro aspecto importante, ya que especifica que una action puede 
tener el mismo nombre en diferentes clases y cada clase ejecutara tal operation de forma 
distinta. 

Los objetos ocultan su funcionalidad de otros objetos y del mundo exterior. Cada objeto 
presenta una interfaz para que otros objetos (y personas) puedan aprovechar su 
funcionalidad. 

Los objetos funcionan en conjunto mediante el envio de mensajes entre ellos. Los 
mensajes son peticiones para realizar operaciones. 

Por lo general, los objetos se asocian entre si y esta asociacion puede ser de diversos 
tipos. Un objeto en una clase puede asociarse con cualquier cantidad de objetos distintos 
en otra clase. 

La agregacion es un tipo de asociacion. Un objeto agregado consta de un conjunto de 
objetos que lo componen y una composition es un tipo especial de agregacion. En 
un objeto compuesto, los componentes solo existen como parte del objeto compuesto. 

Preguntas y respuestas 

P Usted dijo que la orientation a objetos ha tornado por asalto al mundo del 
software. <,Que no hay algunas aplicaciones importantes que no estan orien- 
tadas a objetos? 

R Si, y se conocen como sistemas “heredados” (programas que en muchos casos 
son ejecutados para mostrar su epoca). La orientation a objetos ofrece diversas 
ventajas, como la reusabilidad y un rapido periodo de desarrollo. Por tales razones, 
muy probablemente vera las nuevas aplicaciones (y las versiones redisenadas de 
varias aplicaciones antiguas) escritas bajo el esquema de la orientation a objetos. 



Taller 

Para repasar lo que ha aprendido de la orientation a objetos, intente responder a algunas 
preguntas y realizar los siguientes ejercicios. Las respuestas las encontrara en el 
Apendice A, “Respuestas a los cuestionarios”. 

Cuestionario 

1. ^Que es un objeto? 

2. ^Como trabajan los objetos en conjunto? 

3. ^Que establece la multiplicidad? 

4. ^Pueden asociarse dos objetos entre si en mas de una manera? 



Ejercicios 

Esta es una hora teorica, asi que no inclui ejercicios. Vera algunos en las siguientes 
horas. 




Hora 





Uso de la orientation 
a objetos 

A continuation conjugaremos las caracterfsticas del UML con los conceptos 
de la orientation a objetos. Aquf reafirmara su conocimiento de la orientation 
a objetos al tiempo que aprendera otras cosas del UML. 

En esta hora se trataran los siguientes temas: 

• Concepcion de una clase 

• Atributos 

• Operaciones 

• Responsabilidades y restricciones 

• Que es lo que hacen las clases y como encontrarlas 

Concepcion de una clase 

Como lo indique en la primera hora, en el UML un rectangulo es el simbolo 
que representa una clase. El nombre de la clase es, por convention, una pa- 
labra con la primera letra en mayuscula y normalmente se coloca en la parte 
superior del rectangulo. Si el nombre de su clase consta de dos palabras, 
unalas e inicie cada una con mayuscula (como en Lavadoralndustrial en la 
figura 3.1). 



Figura 3.1 

La representation 
UML de una clase. 



Lavadora I industrial 



Otra estructura del UML, el paquete, puede jugar un papel en el nombre de la clase. 
Como indique en la hora 1, “Introduction al UML”, un paquete es la manera en que el 
UML organiza un diagrama de elementos. Tal vez recuerde que el UML representa un 
paquete como una carpeta tabular cuyo nombre es una cadena de texto (vea la figura 3.2). 



Figura 3.2 

Un paquete del UML 



AT 



Electrodomesticos 



Si la clase “Lavadora” es parte de un paquete llamado “Electrodomesticos”, po- 
dra darle el nombre “Electrodomesticos "Lavadora”. El par de dos puntos separa 
al nombre del paquete, que esta a la izquierda, del nombre de la clase, que va a la dereeha. A 
este tipo de nombre de clase se le conoce como nombre de ruta (vea la figura 3.3). 
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Posiblemente haya notado que en los nombres se han evitado los caracteres 
acentuados (como en Electrodomesticos) y la letra ene. Esto se debe a que 
en el alfabeto ingles, tales caracteres no estan contemplados y no podemos 
asegurar que el utilizarlos en sus identificadores no le traiga problemas, 
tanto en el UML como en el lenguaje de programacion que piense utilizar 
para traducir los modelos. Por ello, evitaremos los acentos en todos los dia- 
gramas que se presentan a lo largo de este libro, de igual manera, evitare- 
mos el uso de la letra ene, misma que sustituiremos — en su caso — por "ni" 
(como en Anio, en lugar de Ano). 



Figura 3.3 

Una clase con un 
nombre de ruta. 



Electrodomesticos: :Lavadora 



Atributos 

Un atributo es una propiedad o caracterfstica de una clase y describe un rango 
de valores que la propiedad podra contener en los objetos (esto es, instancias) 
de la clase. Una clase podra contener varios o ningun atributo. Por convention, si el 
atributo consta de una sola palabra se escribe en minusculas; por otro lado, si el nombre 
contiene mas de una palabra, cada palabra sera unida a la anterior y comenzara con una 
letra mayuscula, a exception de la primer palabra que comenzara en minuscula. La lista 
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de nombres de atributos iniciara luego de una linea que la separe del nombre de la clase, 
como se aprecia en la figura 3.4. 



Figura 3.4 

Una clase y sus 
atributos . 



Lavadora 



marca 

modelo 

numeroSerie 

capacidad 



Todo objeto de la clase tiene un valor especifico en cada atributo. La figura 3.5 le mues- 
tra un ejemplo. Observe que el nombre de un objeto inicia con una letra minuscula, y 
esta precedido de dos puntos que a su vez estan precedidos del nombre de la clase, 
y todo el nombre esta subrayado. 




El nombre miLavadora: Lavadora es una instancia con nombre ; pero tambien 
es posible tener una instancia anonima, como : Lavadora. 



Figura 3.5 

Un objeto cuenta con 
un valor especifico 
en cada uno de los 
atributos que lo 
componen . 



mi Lavadora: Lavadora 



marca - "Laundatorium" 
modelo = "Washmeister“ 
numeroSerie = "GL57774" 
capacidad = 16 



El UML le da la opcion de indicar information adicional de los atributos. En el simbolo 
de la clase, podra especificar un tipo para cada valor del atributo. Entre los posibles tipos 
se encuentran cadena (string), niimero de punto flotante (float), entero (integer) y boolea- 
no (boolean), asf como otros tipos enumerados. Para indicar un tipo, utilice dos puntos 
(:) para separar el nombre del atributo de su tipo. Tambien podra indicar un valor prede- 
terminado para un atributo. La figura 3.6 le muestra las formas de establecer atributos. 




Aunque no parece haber restriccion en la designacion de tipos a las variables, 
utilizaremos los nombres en ingles para cenirnos a los tipos que aparecen en 
los lenguajes de programacion. 







Figura 3.6 

Un atributo puede 
mostrar su tipo 
asi como su valor 
predeterminado . 



Operaciones 

Una operacion es algo que la clase puede realizar, o que usted (u otra clase) 
pueden hacer a una clase. De la misma manera que el nombre de un atributo, 
el nombre de una operacion se escribe en minusculas si consta de una sola palabra. 

Si el nombre constara de mas de una palabra, unalas e inicie todas con mayuscula excep- 
tuando la primera. La lista de operaciones se inicia debajo de una linea que separa a las 
operaciones de los atributos, como se muestra en la figura 3.7. 



Termino Nuevo 



Lavadora 



marca: string = "Laundatorium" 
modelo: string 
numeroSerie: string 
capacidad: integer 



Figura 3.7 

La lista de opera- 
ciones de una clase 
aparece debajo de 
una linea que las 
separa de los atributos 
de la clase. 



Lavadora 



marca 

modelo 

numeroSerie 

capacidad 



agregarRopa() 
sacarRopa() 
ag rega rDete rgente() 
activar() 



Asi como es posible establecer informacion adicional de los atributos, tam- 
bien lo es en lo concemiente a las operaciones. En los parentesis que prece- 
den al nombre de la operacion podra mostrar el parametro con el que funcionara la 
operacion junto con su tipo de dato. La funcion, que es un tipo de operacion, devuelve un 
valor luego que finaliza su trabajo. En una funcion podra mostrar el tipo de valor que 
regresara. 

Estas secciones de informacion acerca de una operacion se conocen como la 
firma de la operacion. La figura 3.8 le muestra como representar la firma. 



Termino Nuevo 



Termino Nuevo 








Figura 3.8 

La firma de una 
operation. 



Lavadora 



marca 

modelo 

numeroSerie 

capacidad 



agregarRopa(C:String) 
sacarRopa(C:String) 
agregarDetergente(D: Integer) 
activar():Boolean 



Atributos, operaciones y concepcion 

Hasta ahora, hemos tratado a las clases como entidades aisladas, y hemos visto todos 
los atributos y operaciones de una clase. No obstante, en la practica mostrara mas de 
una clase a la vez; cuando lo haga, no sera muy util que siempre aparezcan todos los 
atributos y operaciones, ya que el hacerlo le crearfa un diagrama muy saturado. En lugar 
de ello podra tan solo mostrar el nombre de la clase y dejar ya sea el area de atributos o 
el de operaciones (o ambas) vacia, como se muestra en la figura 3.9. 



Figura 3.9 

En la practica, no 
siempre mostrara 
todos los atributos 
y operaciones de 
una clase. 




En ocasiones sera bueno mostrar algunos (pero no todos) de los atributos u 
operaciones. Para indicar que solo ensenara algunos de ellos, seguira la lista 
de aquellos que mostrara con tres puntos (...), mismos que se conocen como puntos sus- 
pensivos . A la omision de ciertos o todos los atributos y operaciones se le conoce como 
abreviar una clase. La figura 3.10 le muestra el uso de los puntos suspensivos. 



Figura 3.10 

Los puntos suspen- 
sivos indican atributos 
u operaciones que 
no se encuentran en 
todo el conjunto. 



Lavadora 



marca 



agregarRopa() 

• • • 



Termino Nuevo 







Si usted tiene una larga lista de atributos u operaciones podra utilizar un estereotipo para 
organizarla de forma que sea mas comprensible. Un estereotipo es el modo en que el 
UML le permite extenderlo, es decir, crear nuevos elementos que son especfficos de 
un problema en particular que intente resolver. Como lo mencione en la hora 1, usted 
muestra un estereotipo como un nombre bordeado por dos pares de parentesis angulares. 
Para una lista de atributos, podra utilizar un estereotipo como encabezado de un sub- 
conjunto de atributos, como en la figura 3.1 1. 



Figura 3.11 

Podra usar un 
estereotipo para 
organizar una lista 
de atributos u 
operaciones. 



Lavadora 



«info identificacion» 

marca 

modelo 

numeroSerie 

«info maquina» 

capacidad 



«relacionado con la ropa>» 
agregarRopa() 
sacarRopaQ 
agregarDetergenteQ 

«relacionado con 
la maquina» 
activar() 




El estereotipo es una estructura flexible, la cual podra utilizar de diversos 
modos. Por ejemplo, podra utilizar el estereotipo sobre el nombre de una 
clase en un simbolo de clase para indicar algo respecto al papel de la clase. 



Responsabilidades y restricciones 

El simbolo de clase le permite establecer otro tipo de information de si misma. 
En un area bajo la lista de operaciones, podra mostrar la responsabilidad de la 
clase. La responsabilidad es una description de lo que hara la clase, es decir, lo que sus 
atributos y operaciones intentan realizar en conjunto. Una lavadora, por ejemplo, tiene la 
responsabilidad de recibir ropa sucia y dar por resultado ropa limpia. 

En el simbolo, indicara las responsabilidades en un area inferior a la que contiene las 
operaciones (vea la figura 3.12). 



Termino Nuevo 






Figura 3.12 

En un simbolo de 
clase, que ira debajo 
de la lista de opera- 
ciones, escribira las 
responsabilidades de 
la clase . 



Lavadora 



«info identificacion» 

marca 

modelo 

numeroSerie 

«info maquina» 

capacidad 



«relacionado con la ropa» 
agregarRopa() 
sacarRopa() 
agregarDetergente() 

«relacionado con 
la maquina» 
activar() 

Recibe ropa sucia y 
devuelve ropa limpia 



La idea es incluir information suficiente para describir una clase de forma inequivoca. 



Termino Nuevo 



Una manera mas formal es agregar una restriction , un texto libre bordeado 
por Haves; este texto especifica una o varias reglas que sigue la clase. Por 
ejemplo, suponga que en la clase Lavadora usted desea establecer que la capacidad de 
una lavadora sera de 7, 8 o 9 Kg (y asi, “restringir” el atributo capacidad de la clase 
Lavadora). Usted escribira {capacidad = 7, 8 o 9 Kg} junto al simbolo de la clase Lava- 
dora. La figura 3.13 le muestra como hacerlo. 



Figura 3.13 

La regia entre Haves 
restringe al atributo 
capacidad para 
contener uno de tres 
posibles valores . 



Lavadora 



marca 

modelo 

numeroSerie 

capacidad 



agregarRopa() 

sacarRopa() 

agregarDetergenteQ 

activar{) 



{capacidad = 7, 8 o 9 Kg} 




El UML funciona con otra forma -aun mas formal- de agregar restricciones 
que hacen mas explicitas las definiciones. Es todo un lenguaje conocido como 
OCL (Lenguaje de restriccion de objetos). OCL cuenta con su propio conjunto 
de reglas, terminos y operadores, lo que lo convierte en una herramienta avan- 
zad a y, en ocasiones, util. 







Notas adjuntas 

Por encima y debajo de los atributos, operaciones, responsabilidades y restricciones, 
puede agregar mayor information a una clase en la figura de notas adjuntas. 

Con frecuencia agregara una nota a un atributo u operation. La figura 3.14 le muestra 
una nota que se refiere a una norma gubemamental que indica donde encontrar la ma- 
nera en que se generan los numeros de serie para los objetos de la clase Lavadora. 



Figura 3.14 

Una nota adjunta 
proporciona mayor 
informacion respecto 
a la clase. 



Lavadora 






marca 

modelo 

numeroSerie 

capacidad 








Vease la norma 
gubemamental EV5-2241 
de los Estados Unidos 


N 


agregarRopa{) 

sacarRopaQ 

agregarDetergenteQ 

activarQ 




para la generacion 
de numeros de serie 










Una nota puede contener tanto una imagen como texto. 



Que es lo que hacen las clases 
y como encontrarlas 

Las clases son el vocabulario y terminologfa de un area del conocimiento. Conforme lia- 
ble con los clientes, analice su area de conocimiento y disene sistemas de computation 
que resuelvan los problemas de dicha area, comprendera la terminologfa y modelara los 
terminos como clases en el UML. 

En sus conversaciones con los clientes preste atencion a los sustantivos que utilizan 
para describir las entidades de sus negocios; ya que dichos sustantivos se convertiran 
en las clases de su modelo. Tambien preste atencion a los verbos que escuche, dado 
que constituiran las operaciones de sus clases. Los atributos surgiran como sustantivos 
relacionados con los nombres de la clase. Una vez que tenga una lista basica de las 
clases, pregunte a los clientes que es lo que cada clase hace dentro del negocio. Sus 
respuestas le indicaran las responsabilidades de la clase. 

Suponga que usted es un analista que generara un modelo del juego de baloncesto, 
y que entrevista a un entrenador para comprender el juego. La conversation podrfa 
surgir como sigue: 






Analista: “Entrenador, ^de que se trata el juego?” 

Entrenador: “Consiste en arrojar el balon a traves de un aro, conocido como cesto, y 
hacer una mayor puntuacion que el oponente. Cada equipo consta de cinco jugadores: 
dos defensas, dos delanteros y un central. Cada equipo lleva el balon al cesto del equipo 
oponente con el objetivo de hacer que el balon sea encestado ” 

Analista: “^Como se hace para llevar el balon al otro cesto?” 

Entrenador: “Mediante pases y dribles. Pero el equipo tendra que encestar antes de que 
termine el lapso para tirar ” 

Analista: “^El lapso para tirar?” 

Entrenador: “Asf es, son 24 segundos en el baloncesto profesional, 30 en un juego intema- 
cional, y 35 en el colegial para tirar el balon luego de que un equipo toma posesion de el.” 

Analista: “^Como funciona el puntaje?” 

Entrenador: “Cada canasta vale dos puntos, a menos que el tiro haya sido hecho detrds 
de la Ifnea de los tres puntos. En tal caso, seran tres puntos. Un tiro libre contara como un 
punto. A proposito, un tiro libre es la penalization que paga un equipo por cometer una 
infraccion. Si un jugador infracciona a un oponente, se detiene el juego y el oponente 
puede realizar diversos tiros al cesto desde la linea de tiro libre ” 

Analista: “Hableme mas acerca de lo que hace cada jugador.” 

Entrenador: “Quienes juegan de defensa son, en general, quienes realizan la mayor parte 
de los dribles y pases. Por lo general tienen menor estatura que los delanteros, y estos, a 
su vez, son menos altos que el central (que tambien se conoce como ‘poste’). Se supone 
que todos los jugadores pueden burlar, pasar, tirar y rebotar. Los delanteros realizan la 
mayorfa de los rebotes y los disparos de mediano alcance, mientras que el central se 
mantiene cerca del cesto y dispara desde un alcance corto.” 

Analista: “^Que hay de las dimensiones de la cancha? Y ya que estamos en eso ^cuanto 
dura el juego?” 

Entrenador: “En un juego intemacional, la cancha mide 28 metros de longitud y 15 de 
ancho; el cesto se encuentra a 3.05 m del piso. En un juego profesional, el juego dura 
48 minutos, divididos en cuatro cuartos de 12 minutos cada uno. En un juego colegial 
e intemacional, la duration es de 40 minutos, divididos en dos mitades de 20 minutos. 
Un cronometro del juego lleva un control del tiempo restante ” 

La platica podrfa continuar, pero hagamos una pausa y veamos con que contamos. Aquf 
hay varios sustantivos que ha descubierto: balon, cesto, equipo, jugadores, defensas, 
delanteros, centro (o poste), tiro, lapso para tirar, linea de los tres puntos, tiro libre, 
infraccion, linea de tiro libre, cancha, cronometro del juego. 

Y los verbos: tirar, avanzar, driblar (o burlar), pasar, infraccionar, rebotar. Tambien 
cuenta con cierta information adicional respecto a algunos de los sustantivos (como las 




estaturas relativas de los jugadores de cada position, las dimensiones de la cancha, la 
cantidad total de tiempo en un lapso de tiro y la duration de un juego). 

Finalmente, su propio sentido comun podrfa entrar en action para generar ciertos atribu- 
tos por usted mismo. Usted sabe, por ejemplo, que el balon cuenta con ciertos atributos, 
como volumen y diametro. 

A partir de esta information, podra crear un diagrama como el de la figura 3.15. En 
el se muestran las clases y se proporcionan ciertos atributos, operaciones y restricciones. 
El diagrama tambien muestra las responsabilidades. Podrfa usar este diagrama como 
fundamento para otras conversaciones con el entrenador para obtener mayor information. 



Figura 3.15 

Un diagrama inicial 
para modelar el juego 
de baloncesto . 



Balon 




Jugador 




Defensa 


diametro 




nombre 

estatura 

peso 






volumen 








driblar() 

tirar() 

pasar() 

avanzar() 




driblarBalonQ 

pasarBalon() 

tirarBalon() 

rebotar() 

infraccionarOponenteQ 




realiza 
la mayor 
parte del 
drible y pase 








Delantero 




Centro 




Tiro 




















realiza 

la mayor parte 
de los tiros 




permanece 
cerca del cesto, 




Linea 

DeTresPuntos 


de media distancia 
y rebotes 




tira de una 
distancia cercana 










Tiro Libre 






LapsoDeTiro 


{profesional = 24 segs. 
colegial = 35 segs. 
internacional = 30 segs.} 













{profesional = 4 cuartos 
de 12 mins, colegial e 
internacional = 2 mitades 
de 20 mins.} 


Linea 

DeTiroLibre 


CronometroDeJuego 










Duracion 


{profesional = 48 mins, 
colegial e internacional = 
40 mins.} 


Cancha 

















Resumen 

Un rectangulo es, en el UML, la representation simbolica de una clase. El nombre, 
atributos, operaciones y responsabilidades de la clase se colocan en dreas delimitadas 
dentro del rectangulo. Puede utilizar un estereotipo para organizar las listas de atributos 
y operaciones y ademas abreviar una clase al mostrar solo un subconjunto de sus atri- 
butos y operaciones. Esto hace un diagrama de clases menos complejo. 

Podra mostrar el tipo de un atributo, su valor inicial y ensenar los valores con que funciona 
una operation, asi como sus tipos. En una operation, esta information se conoce como 
firma. 

Para reducir la ambigiiedad en la description de una clase agregue restricciones. El UML 
tambien le permite indicar mayor information respecto a una clase mediante 
notas adjuntas al rectangulo que la representa. 

Las clases representan el vocabulario de un area del conocimiento. Las conversaciones 
con el ciiente o un experto en el area dejaran entrever los sustantivos que se convertiran 
en clases en un modelo, y los verbos se transformaran en operaciones. Podra utilizar un 
diagrama de clases como una forma de estimular al ciiente a que diga mas respecto a su 
area y que ponga en evidencia cierta information adicional. 

Preguntas y respuestas 

P Usted menciono el uso del “sentido comun” para generar el diagrama de 
clases del baloncesto. Elio suena bien en tal instancia pero, £que ocurre 
cuando tengo que analizar un area desconocida para mi (donde el sentido 
comun no sera de mucha ayuda)? 

R Por lo general, contara con cierto apoyo en un area desconocida para usted. Antes 
de que se reuna con un ciiente o con un experto en el campo, intente convertirse 
en un “subexperto”. Preparese para la reunion y lea cuanta documentation rela- 
cionada tenga a la mano. Pregunte a sus entrevistados respecto a documentos o 
manuales que hayan escrito. Cuando haya terminado de leer, tendra cierto conoci- 
miento basico y podra realizar las preguntas indicadas. 

P ^En que momento tendria que mostrar la firma de una operation? 

R Tal vez, luego de la fase de analisis de un proceso de desarrollo, conforme se 
adentre en el diseno. La firma es una section de information que los desarrolla- 
dores podrfan encontrar muy util. 




Taller 

Para repasar lo que ha aprendido respecto a la orientacion a objetos, intente responder a 
las siguientes preguntas. Las respuestas las encontrara en el Apendice A, “Respuestas 
a los cuestionarios”. 

Cuestionario 

1. ^Como representa una clase en el UML? 

2. <,Que informacion puede mostrar en un simbolo de clase? 

3. iQue es una restriction? 

4. ^Para que adjuntaria una nota a un simbolo de clase? 

Ejercicios 

L He aqui una breve (e incompleta) description del balompie: 

Un equipo de balompie (o futbol soccer) consiste en 1 1 jugadores de campo 
( 1 portero y el resto, jugadores de cancha que, en ocasiones, se organizan en cuatro 
defensas, tres centrales y tres delanteros). Los jugadores pueden usar cualquier 
parte de su cuerpo (excepto las manos) para introducir el balon a la porterfa del 
equipo contrario. La unica exception a esta regia la tiene el portero, quien puede 
utilizar tambien las manos para jugar el balon, pero solo dentro del area de meta. 

El campo de juego es un rectangulo de una longitud maxima de 120 m y minima 
de 90 m; y con una anchura no mayor de 90 m, ni menor de 45. Para partidos 
intemacionales, la longitud sera de 110 m como maximo y 100 como minimo; 
y una anchura no superior a 75 m ni inferior a 64. En cualquier caso, debera ser 
mayor la longitud que la anchura. El campo de juego se dividira en dos mitades 
transversales de igual tamano. El centro del campo sera marcado con un punto 
visible, alrededor del cual se trazara una circunferencia de 9.15 m de radio. La 
meta del juego es pasar el balon a los delanteros, quienes estan mejor preparados 
para patear el balon a la porterfa. El portero (o arquero) es la ultima lmea de 
defensa que intentara bloquear, con cualquier parte de su cuerpo, los tiros de sus 
opositores. Cada vez que evita un gol, es decir, que el balon entre a la porterfa, 
habra salvado su meta. Cada gol equivale a un punto. Un juego dura 90 minutos, 
divididos en dos periodos de 45 minutos cada uno. 

Valgase de la anterior informacion para crear un diagrama como el de la figura 
3.15. Si usted conoce mas del balompie de lo que he descrito, agregue tal informa- 
cion a su diagrama. 

2. Si usted conoce mas del baloncesto de lo que hay en la figura 3.15, agregue la 
informacion a tal diagrama. 




Hora 4 




Uso de relaciones 

En la hora anterior creamos un conjunto de clases que representaban el 
vocabulario del baloncesto. Aunque ello le da las bases para una mayor 
exploration de lo que es el baloncesto, tal vez haya sentido que algo le falta. 

Ese “algo” es un sentido en el que las clases se relacionan entre si. Si 
observa el modelo (vea la figura 3.15), vera que no se indica la manera en 
que un jugador se relaciona con un balon, ni como los jugadores confor- 
man un equipo, ni la forma en que procede el juego. Es como si hubiera 
construido una lista de elementos, en lugar de una representation de un 
area del conocimiento. Es importante saber como se conectan las clases 
entre si. 

Ahora trazaremos las conexiones entre las clases y completaremos la re- 
presentacion. 

En esta hora se trataran los siguientes temas: 

• Asociaciones 

• Multiplicidad 

• Asociaciones calificadas 



• Asociaciones reflexivas 

• Herencia y generalization 

• Dependencias 

Asociaciones 

Cuando las clases se conectan entre sf de forma conceptual, esta conexion se 
conoce como asociacion. El modelo inicial de baloncesto le dara algunos 
ejemplos. Examinemos uno de ellos: la asociacion entre un jugador y un equipo. Podra 
caracterizar tal asociacion con la frase: “un jugador participa en un equipo”. Visualizara 
la asociacion como una linea que conectara a ambas clases, con el nombre de la aso- 
ciacion (“participa en”) justo sobre la linea. Es util indicar la direction de la relation, y 
lo hara con un triangulo relleno que apunte en la direction apropiada. La figura 4. 1 le 
muestra como visualizar la asociacion “Participa en” entre el jugador y el equipo. 
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Figura 4.1 

Una asociacion entre 
un jugador y un 
equipo. 




Cuando una clase se asocia con otra, cada una de ellas juega un papel dentro de tal aso- 
ciacion. Puede representar estos papeles en el diagrama escribiendolos cerca de la linea 
que se encuentra junto a la clase que juega el papel correspondiente. En la asociacion 
entre un jugador y un equipo, si el equipo es profesional, este es un empleador y el 
jugador es un empleado. La figura 4.2 le muestra como representar dichos papeles. 



Figura 4.2 

Por lo general en una 
asociacion cada clase 
juega un papel. Puede 
representar tales pape- 
les en el diagrama. 



Jugador 


Participa en ^ 


Equipo 




Empleado Empleador 





La asociacion puede funcionar en direction inversa: un equipo emplea a jugadores. 
Podra mostrar ambas asociaciones en el mismo diagrama con un triangulo relleno que 
indique la direction de cada asociacion, como en la figura 4.3. 








Figura 4.3 

Pueden aparecer dos 
asociaciones entre 
clases en el mismo 
diagrama . 



Jugador 


Participa en ► 


Equipo 


A Emplea 









Las asociaciones podrian ser mas complejas que tan solo una clase conectada a otra. Varias 
clases se pueden conectar a una. Si toma en cuenta los defensas, delanteros y central, asi 
como sus asociaciones con la clase Equipo, tendra el diagrama de la figura 4.4. 



Figura 4.4 

Pueden asociarse 
diversas clases con 
una en particular. 




Restricciones en las asociaciones 

En ocasiones una asociacion entre dos clases debe seguir cierta regia. Esta se indica al 
establecer una restriccion junto a la linea de asociacion. Por ejemplo: un Cajero atiende a 
un Cliente, pero cada Cliente es atendido en el orden en que se encuentre en la forma- 
cion. Puede capturar este modelo colocando la palabra ordenado entre Haves (para 
indicar la restriccion) junto a la clase Cliente, como se ve en la figura 4.5. 

Figura 4.5 

Puede establecer una 
restriccion en una 
asociacion. En este 
caso, la asociacion 
Atiende esta restringida 
para que el Cajero 
atienda al Cliente 
en turno. 




Otro tipo de restriccion es la relation O (distinguida como {Or}) en una linea discon- 
tinua que conecte a dos lineas de asociacion. La figura 4.6 modela a un estudiante de 
education media superior que elegira entre un curso academico o uno comercial. 









Figura 4.6 

La relation O entre 
dos asociaciones en 
una restriction. 




Clases de asociacion 

Una asociacion, al igual que una clase, puede contener atributos y operaciones. 
De hecho, cuando este sea el caso, usted tendra una clase de asociacion. 

Puede concebir a una clase de asociacion de la misma forma en que lo harfa con una 
clase estandar, y utilizara una linea discontinua para conectarla a la linea de asociacion. 
Una clase de asociacion puede tener asociaciones con otras clases. La figura 4.7 le mues- 
tra una clase de asociacion para la asociacion “Participa en” entre un jugador y un 
equipo. La clase de asociacion, Contrato, se asocia con la clase DirectorGeneral. 
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Figura 4.7 

Una clase de asociacion 
modela los atributos y 
operaciones de una 
asociacion . Se conecta 
a una asociacion me- 
diante una linea dis- 
continua , y puede 
asociarse a otra clase. 




Vmculos 

Asi como un objeto es una instancia de una clase, una asociacion tambien cuenta con 
instancias. Si podemos imaginar a un jugador especifico que juega para un equipo 
especifico, la relacion “Participa en” se conocera como vinculo , y usted lo representara 
como una linea que conecta a dos objetos. Tal como tuvo que subrayar el nombre de un 
objeto, debera subrayar el nombre de un vinculo, como en la figura 4.8. 



Figura 4.8 

Un vinculo es la instan- 
cia de una asociacion. 
Conecta a los objetos 
en lugar de las clases. 
Debera subrayar el 
nombre del vinculo, 
como se hace en el 
nombre de un objeto. 












Multiplicidad 

La asociacion trazada entre Jugador y Equipo sugiere que las dos clases tienen una 
relation de uno a uno. No obstante, el sentido comun nos indica que este no es el caso. 
Un equipo de baloncesto cuenta con cinco jugadores (sin contar a los sustitutos). La 
asociacion Tiene (Has) debe participar en este recuento. En la otra direction, un jugador 
puede participar solo en un equipo, y la asociacion “Participa en” debe responder de 
esto. 

Tales especificaciones son ejemplos de la multiplicidad : la cantidad de objetos 
de una clase que se relacionan con un objeto de la clase asociada. Para repre- 
sentar los numeros en el diagrama, los colocara sobre la lfnea de asociacion junto a la 
clase correspondiente, como se denota en la figura 4.9. 
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Figura 4.9 

La multiplicidad 
sehala la cantidad 
de objetos de una 
clase que pueden 
relacionarse con un 
objeto de una clase 
asociada. 




La multiplicidad de este ejemplo no es la unica que existe. Hay varios tipos de multipli- 
cidades (una multiplicidad de multiplicidades, por decirlo asQ. Una clase puede rela- 
cionarse con otra en un esquema de uno a uno, uno a muchos, uno a uno o mas, uno a 
ninguno o uno, uno a un intervalo definido (por ejemplo: uno a cinco hasta diez), uno a 
exactamente n (como en este ejemplo), o uno a un conjunto de opciones (por ejemplo, 
uno a nueve o diez). El UML utiliza un asterisco (*) para representar mas y para repre- 
sentar muchos. En un contexto O se representa por dos puntos, como en “1..*” (“uno o 
mas”). En otro contexto, O se representa por una coma, como en “5, 10” (“5 o 10”). La 
figura 4.10 le muestra como concebir las posibles multiplicidades. 




Cuando la clase A tiene una multiplicidad de uno a ninguno o uno con la 
clase B, la clase B se dice que es opcional para la clase A. 






Figura 4.10 

Posibles multiplici- 
dades y como repre- 
sentarlas en el UML. 




uno a uno 



uno a muchos 



uno a uno o mas 



uno a ninguno o uno 



uno a 12 hasta 18 



uno a tres 



uno a 12 o 24 



Asociaciones calificadas 

Cuando la multiplicidad de una asociacion es de uno a muchos, con frecuencia se pre- 
senta un reto muy particular: la busqueda. Cuando un objeto de una clase tiene que selec- 
cionar un objeto particular de otro tipo para cumplir con un papel en la asociacion, la 
primera clase debera atenerse a un atributo en particular para localizar al objeto ade- 
cuado. Normalmente, dicho atributo es un identificador que puede ser un numero de 
identidad. Por ejemplo, cuando usted realiza una reservation en un hotel, el hotel le 
asigna un numero de confirmacion. Si usted quiere hacer preguntas respecto a la reser- 
vacion, debera proporcionar el numero de confirmacion. 

En el UML la information de identidad se conoce como calificador. Su sim- 
bolo es un pequeno rectangulo adjunto a la clase que hara la busqueda. La 
figura 4. 1 1 muestra la representation. La idea es reducir, con eficiencia, la multiplicidad 
de uno a muchos a una multiplicidad de uno a uno. 
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Figura 4.11 



Un calificador en una 
asociacion resuelve el 
problema de la 
busqueda. 

Asociaciones reflexivas 

En ocasiones, una clase es una asociacion consigo misma. Esto puede ocurrir cuando una 
clase dene objetos que pueden jugar diversos papeles. Un OcupanteDeAutomovil puede 
ser un Conductor o un Pasajero. En el papel del conductor, el OcupanteDeAutomovil 
puede llevar ninguno o mas OcupanteDeAutomovil, quienes jugaran el papel de 
pasajeros. Esto lo representara mediante el trazado de una linea de asociacion a partir del 
rectangulo de la clase hacia el mismo rectangulo de la clase, y en la linea de asociacion 
indicara los papeles, nombre de la asociacion, direccion de la asociacion y multiplicidad 
como ya lo hizo antes. La figura 4.12 le presenta este ejemplo. 



Recepcionista 








Numero de confirmacionl 








Figura 4.12 

En una asociacion 
reflexiva, trazard la 
linea de la clase hacia 
si misma y podrd 
incluir los papeles , 
nombre de la asocia- 
cion y su direccion, asi 
como su multiplicidad. 



Conduce 

▼ 



1 


OcupanteDeAutomovil 


conductor 




0..4 


pasajero 



Herencia y generalizacion 

Uno de los sellos distintivos de la orientacion a objetos es que captura uno de los ma- 
yores aspectos del sentido comun en cuanto a la vida diaria: si usted conoce algo de una 
categorfa de cosas, automaticamente sabra algunas cosas que podra transferir a otras cate- 
gories. Si usted sabe que algo es un electrodomestico, ya sabra que contara con un in- 
terruptor, una marca y un numero de serie. Si sabe que algo es un animal dara por hecho 
que come, duerme, tiene una forma de nacer, de trasladarse de un lugar a otro y algunos 
otros atributos (y operaciones) que podria listar si pensara en ello por algunos instantes. 

La orientacion a objetos se refiere a esto como herencia. El UML tambien lo 
denomina generalizacion . Una clase (la clase secundaria o subclase) puede 
heredar los atributos y operaciones de otra (la clase principal o superclase). La clase 
principal (o madre) es mas generica que la secundaria (o hija). 
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En la generalization, una clase secundaria (hija) es sustituible por una clase 
principal (madre). Es decir, donde quiera que se haga referencia a la clase 
madre, tambien se hace referencia a la clase hija. Sin embargo, en el caso 
contrario no es aplicable. 



La jerarquia de la herencia no tiene que finalizar en dos niveles: una clase secundaria 
puede ser principal para otra clase secundaria. Un Mamffero es una clase secundaria de 
Animal, y Caballo es una clase secundaria de Mamffero. 

En el UML representara la herencia con una lfnea que conecte a la clase principal con la 
secundaria. En la parte de la lfnea que se conecta con la clase principal, colocara un 
triangulo sin rellenar que apunte a la clase principal. Este tipo de conexion se interpreta 
con la frase es un tipo de. Un Mamffero es un tipo de Animal, y un Caballo es un tipo de 
Mamffero. La figura 4.13 le muestra esta particular jerarquia de la herencia, junto con 
otras clases. Observe la apariencia del triangulo y las lfneas cuando varias clases secun- 
darias son herencia de una clase principal. A1 disponer el diagrama de este modo, trae 
por resultado un diagrama mas ordenado en lugar de mostrar todas las lfneas y triangu- 
los, aunque el UML no le prohfbe colocarlos todos en la imagen. Tambien vea que no 
coloco los atributos y operaciones heredadas en los rectangulos de las subclases, dado 
que ya los habfa representado en la superclase. 











Con frecuencia las clases secundarias agregan otras operaciones y atributos a los que han 
heredado. Por ejemplo: un Mamifero tiene pelo y da leche, dos atributos que no se 
encuentran en la clase Animal. 



Termino Nuevo 



Una clase puede no provenir de una clase principal, en cuyo caso sera una clase 
base o clase rai'z . Una clase podria no tener clases secundarias, en cuyo caso 
sera una clase final o clase hoja. Si una clase tiene exactamente una clase principal, tendril 
una herencia simple. Si proviene de varias clases principals, tendra una herencia multiple. 



Descubrimiento de la herencia 

En el proceso de platica con un cliente, un analista descubrira la herencia de varias for- 
mas. Es posible que las clases candidatas que aparezcan incluyan tanto clases principales 
como clases secundarias. El analista debera darse cuenta que los atributos y operaciones 
de una clase son generates y que se aplicaran a, quiza, varias clases (mismas que agre- 
garan sus propios atributos y operaciones). 

El ejemplo del baloncesto de la hora 3, “Uso de la orientacion a objetos”, tiene las clases 
Jugador, Defensa, Delantero y Central. El Jugador tiene atributos como nombre, estatura, 
peso, velocidadAlCorrer y salto Vertical. Tiene operaciones como driblar(), pasar(), rebotarQ 
y tirar(). Las clases Defensa, Delantero y Centro heredaran tales atributos y operaciones, y 
agregaran los suyos. La clase Defensa podria tener las operaciones correrAlFrente() y 
quitarBalon(). El Central podria tener retacarBalon(). De acuerdo con los comentarios 
del entrenador respecto a las estaturas de los jugadores, el analista tal vez quisiera colo- 
car restricciones en las estaturas para cada position. 

Otra posibilidad es que el analista note que dos o mas clases tienen ciertos atributos y 
operaciones en comun. El modelo del baloncesto tiene un CronometroDeJuego (que con- 
trola el tiempo que resta en un periodo de juego) y un LapsoDeTiro (que controla el 
tiempo restante desde el instante que un equipo tomo posesion del balon, hasta que 
intente encestar). Si nos damos cuenta de que ambos controlan el tiempo, el analista 
podria formular una clase Reloj con una operation controlarTiempo() que podrian 
heredar tanto CronometroDeJuego como LapsoDeTiro. 




Dado que LapsoDeTiro controla 24 segundos (profesional) o 35 segundos 
(colegial) y el CronometroDeJuego controla 12 minutos (profesional) o 20 
minutos (colegial), controlarTiempoQ sera polimorfico. 



Clases abstractas 

En el modelo del baloncesto, el par de clases que mencione — Jugador y Reloj — son 
utiles puesto que funcionan como clases principales para clases secundarias importantes. 
Las clases secundarias son importantes en el modelo dado que finalmente usted querra 





tener instancias de tales clases. Para desarrollar el modelo, necesitara instancias de 
Defensa, Delantero, Centro, CronometroDeJuego y LapsoDeTiro. 

No obstante, Jugador y Reloj no proporcionan ninguna instancia al modelo. Un objeto de 
la clase Jugador no servirfa a ningun proposito, asi como tampoco uno de la clase Reloj. 

Las clases como Jugador y Reloj — que no proveen objetos — se dice que son 
abstractas. Una clase abstracta se distingue por tener su nombre en cursivas. 
La figura 4.14 muestra las dos clases abstractas y sus clases secundarias. 
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Figura 4.14 

Dos jerarqutas de 
herencia con clases 
abstractas en el 
modelo de baloncesto. 




Dependencias 

En otro tipo de relacion, una clase utiliza a otra. A esto se le llama dependen- 
ce. El uso mas comun de una dependencia es mostrar que la firma de la 
operacion de una clase utiliza a otra clase. 

Suponga que disenara un sistema que muestra formularios corporativos en pantalla para 
que los empleados los llenen. El empleado utiliza un menu para seleccionar el formula- 
rio por llenar. En su diseno, tiene una clase Sistema y una clase Formulario. Entre sus 
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muchas operaciones, la clase Sistema tiene mostrarFormulario(f:Form). El formulario 
que el sistema desplegara, dependera, obviamente, del que elija el usuario. La notation 
del UML para ello es una linea discontinua con una punta de flecha en forma de trian- 
gulo sin relleno que apunta a la clase de la que depende, como muestra la figura 4.15. 

Figura 4.15 

Una flecha represen- 
tada por una linea 
discontinua con una 
punta de flecha en 
forma de triangulo sin 
relleno simboliza una 
dependencia. 



Resumen 

Sin las relaciones, un modelo de clases sena poco menos que una lista de cosas que repre- 
sentanan un vocabulario. Las relaciones le muestran como se conectan los terminos del 
vocabulario entre si para dar una idea de la section del mundo que se modela. La asociacion 
es la conexion conceptual fundamental entre clases. Cada clase en una asociacidn juega un 
papel, y la multiplicidad especifica cuantos objetos de una clase se relacionan con un objeto 
de la clase asociada. Hay muchos tipos de multiplicidad. Una asociacion se representa como 
una linea entre los rectangulos de clases con los papeles y multiplicidades en cada extremo. 
A1 igual que una clase, una asociacion puede contener atributos y operaciones. 

Una clase puede heredar atributos y operaciones de otra clase. La clase heredada es secun- 
daria de la clase principal que es de la que se hereda. Descubrira la herencia cuando 
encuentre clases en su modelo initial que tengan atributos y operaciones en comun. Las 
clases abstractas solo se proyectan como bases de herencia y no proporcionan objetos por 
si mismas. La herencia se representa como una linea entre la clase principal y la secun- 
daria, con un triangulo sin rellenar que se adjunta (y apunta a) la clase principal. 

En una dependencia, una clase utiliza a otra. El uso mas comun de una dependencia es 
mostrar que una firma en la operation de una clase utiliza a otra clase. Una dependencia 
se proyecta como una linea discontinua que reune a las dos clases en la dependencia, con 
una punta de flecha en forma de triangulo sin relleno que adjunta (y apunta a) la clase de 
la que se depende. 

Preguntas y respuestas 

P ^En alguna ocasion se le puede poner nombre a una relation de herencia, 
como se hace en una asociacion? 

R El UML no le impide que adjudique un nombre a una relation de herencia, pero 
por lo general esto no es necesario. 



Sistema 



mostrarFormularioO 



Formulario 





Taller 

El cuestionario y los ejercicios se han disenado para reafirmar su conocimiento del UML 
en el area de las relaciones. Cada pregunta y ejercicio requiere que usted piense en la 
simbologfa del modelado que ha aprendido y la aplique a una situacion. Las respuestas 
se encuentran en el Apendice A, “Respuestas a los cuestionarios”. 

Cuestionarios 

1 . ^Como representana la multiplicidad? 

2. ^Como descubrira la herencia? 

3. ^Que es una clase abstracta? 

4. ^Cual es el efecto de un calificador? 

Ejercicios 

1. Tome como base el modelo del baloncesto de la Hora 3, y agregue vinculos que 
expresen las relaciones que ha visto en esta hora. Si conoce el juego del balon- 
cesto, sientase con libertad de agregar los vinculos que representen su 
conocimiento. 

2. De acuerdo con un viejo adagio: “Un abogado que se defiende a si mismo, tiene 
por cliente a un tonto.” Cree un modelo que refleje esta pieza de sabiduria. 




Hora 





Agregacion, 
composition, 
interfaces 
y realization 

Continuaremos con las relaciones entre clases y comprendera nuevos con- 
cepts respecto a las clases y sus diagramas. 

En esta hora se trataran los siguientes temas: 

• Agregaciones 

• Composiciones 

• Contexts 

• Interfaces y realizaciones 

• Visibilidad 



Ya ha visto lo concemiente a asociacion, multiplicidad y herencia y esta casi listo para 
crear diagramas de clases significativos. Conforme explore otros tipos de relaciones y 
detalles relacionados con las clases comprendera las piezas finales del rompecabezas. La 
meta final es crear una idea estatica de un sistema, con todas las conexiones entre las 
clases que lo conforman. 

Agregaciones 

En ocasiones una clase consta de otras clases. Este es un tipo especial de 
relation conocida como agregacion o acumulacion. Los componentes y la 
clase que constituyen son una asociacion que conforma un todo. En la hora 2, 
’’Orientation a objetos”, mencione que su computadora es un conjunto de elementos que 
consta de gabinete, teclado, raton, monitor, unidad de CD-ROM, una o varias unidades 
de disco duro, modem, unidad de disquete, impresora y, posiblemente, altavoces. Ademas 
de las unidades de disco, el gabinete contiene la memoria RAM, una tarjeta de video y 
una tarjeta de sonido (tal vez algunos otros elementos). 

Puede representar una agregacion como una jerarqufa dentro de la clase completa (por 
ejemplo el sistema computacional) en la parte superior, y los componentes por debajo de 
ella. Una lfnea conectara el todo con un componente mediante un rombo sin relleno que 
se colocara en la lfnea mas cercana al todo. La figura 5.1 le muestra el sistema de 
computo como una agregacion. 
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Figura 5.1 

Una asociacion por 
agregacion se repre- 
senta por una linea 
entre el componente y 
el todo con un rombo 
sin relleno que con- 
forma al todo . 




Aunque este ejemplo le muestra cada componente correspondiente a un todo, en una 
agregacion este no sera necesariamente el caso. Por ejemplo: en un sistema casero de 
entretenimiento, un control remoto podrfa ser un componente de una television, aunque 
tambien podrfa ser un componente de una reproductora de casetes de video. 











Restricciones en las agregaciones 

En ocasiones el conjunto de componentes posibles en una agregacion se establece dentro 
de una relacion O. En ciertos restaurantes, una comida consta de sopa o ensalada, el 
plato fuerte y el postre. Para modelar esto, utilizarfa una restriccion: la palabra O dentro 
de Haves con una linea discontinua que conecte las dos lineas que conforman al todo, 
como lo muestra la figura 5.2. 



Figura 5.2 

Puede establecer una 
restriccion a una agre 
gacion para mostrar 
que un component e a 
otro es parte del todo. 




Composiciones 

Una composition es un tipo muy representativo de una agregacion. Cada componente 
dentro de una composition puede pertenecer tan solo a un todo. Los componentes de una 
mesa de cafe (la superficie de la mesa y las patas) establecen una composicion. El sim- 
bolo de una composicion es el mismo que el de una agregacion, excepto que el rombo 
esta relleno (vea la figura 5.3). 



Figura 5.3 

En una composicion, 
cada componente 
pertenece solamente 
a un todo . Un rombo 
relleno representa 
esta relacion. 




Contextos 

Cuando modele un sistema podnan producirse, con frecuencia, agrupamientos de clases, 
como agregaciones o composiciones. En tal caso, debera enfocar su atencion en un agru- 
pamiento o en otro, y el diagrama de contexto le proporciona la caracteristica de mode- 
laje que requiere para tal fin. Las composiciones figuran en gran medida dentro de los 
diagramas de contexto. Un diagrama de contexto es como un mapa detallado de alguna 
section de un mapa de mayores dimensiones. Pueden ser necesarias varias secciones para 
capturar toda la information detallada. 











He aquf un ejemplo: suponga que esta creando un modelo de una camisa y la forma en 
que se podrfa combinar con algun atuendo y un guardarropa. Un tipo de diagrama de 
contexto (vea la figura 5.4) le mostrara la camisa como un gran rectangulo de clase, con 
un diagrama anidado en el interior, el cual le muestra como los componentes de la 
camisa estan relacionados entre si. Este es un diagrama de contexto de composicion 
(dado que la sola camisa reune a cada componente se le denomina de composicion ). 



Figura 5,4 

Un diagrama de con- 
texto de composicion 
le muestra los compo- 
nentes de una clase 
como un diagrama 
anidado dentro de un 
enorme rectangulo de 
clase. 




El diagrama de contexto de composicion enfoca la atencion en la camisa y sus compo- 
nentes. Para mostrar la camisa en el contexto del guardarropa y de algun atuendo, tendra 
que ampliar su ambito. Un diagrama de contexto del sistema lo hara por usted. Podra 
mostrar la forma en que la clase Camisa se conecta con las clases Guardarropa y 
Atuendo, como se ve en la figura 5.5. 



Figura 5.5 

Un diagrama de 
contexto del sistema 
le muestra los com- 
ponentes de una 
clase y la forma 
en que la clase se 
relaciona con las 
otras que hay en 
el sistema. 













Podra ver de cerca alguna otra clase y presentar sus detalles en algun otro diagrama de 
contexto. 

Interfaces y realizaciones 

Una vez que haya creado varias clases, tal vez se de cuenta que no pertenecen a una 
clase principal, pero en su comportamiento debe incluir algunas de las mismas opera- 
ciones con las mismas firmas de la primera clase. Podria codificar las operaciones en 
una de las clases y reutilizarlas en otras. Una segunda posibilidad es que desarrolle una 
serie de operaciones para las clases en un sistema, y reutilizarlas para las clases de otro 
sistema. 



De cualquier manera, deseara contar con algun medio para capturar el con- 
junto reutilizable de operaciones. La interfaz es la estructura del UML que le 
permite hacerlo. Una interfaz es un conjunto de operaciones que especifica cierto aspecto 
de la funcionalidad de una clase, y es un conjunto de operaciones que una clase presenta 
a otras. 

Con un ejemplo podriamos aclarar lo anterior. El teclado que usted utiliza para comuni- 
carse con su equipo es una interfaz reutilizable. Su operacion basada en la opresion de 
teclas ha provenido de la maquina de escribir. La disposition de las teclas es casi la 
misma que en una maquina de escribir, pero el punto principal es que la operacion por 
opresion de teclas ha sido cedida de un sistema a otro. Otras operaciones (Mayus, Bloq 
Mayus y Tab) tambien se integraron a partir de la maquina de escribir. 

Por supuesto, el teclado de una computadora incluye diversas operaciones que no encon- 
trara en una maquina de escribir: Control, Alt, RePag, AvPag y otras. Asi pues, la inter- 
faz puede establecer un subconjunto de las operaciones de una clase y no necesariamente 
todas ellas. 

Puede modelar una interfaz del mismo modo en que modelaria una clase, con un sim- 
bolo rectangular. La diferencia sera que, como un conjunto de operaciones, una interfaz 
no tiene atributos. Recordara que puede omitir los atributos de la representation de una 
clase. ^Entonces, como distinguiria entre una interfaz y una clase que no muestra sus 
atributos? Una forma es utilizar la estructura “estereotipo” y especificar la palabra 
«interfaz» sobre el nombre de la interfaz en el rectangulo. Otra es colocar la letra “I” al 
principio del nombre de una interfaz. 

En cierto sentido, es como si el teclado de la computadora garantizara que 
esta parte de su funcionalidad “harfa las veces” del teclado de una maquina de 
escribir. Bajo este esquema, la relacion entre una clase y una interfaz se conoce como 
realizacion. Esta relacion esta modelada como una linea discontinua con una punta de 
flecha en forma de triangulo sin rellenar que adjunte y apunte a la interfaz. La figura 5.6 
le muestra como se lleva a cabo esto. 
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Figura 5.6 

Una interfaz es un con- 
junto de operaciones 
que realiza una clase. 
Esta ultima se relaciona 
con una interfaz me- 
diante la realizacion, 
misma que se indica por 
una linea discontinua 
con una punta de flecha 
en forma de triangulo 
sin rellenar que apunte 
a la interfaz . 



Teclado 






marca 

cantidadDeTeclas 


t> 


«interfaz» 

Maquina 

DeEscribir 


Ctrl() 

Alt() 

RePagO 

AvPagQ 


Teclazo() 



Otra forma (omitida) de representar una clase y su interfaz es con un pequeno circulo 
que se conecte mediante una linea a la clase, como se ve en la figura 5.7. 

Figura 5.7 

La forma omitida de 
representar una clase 
que realice una interfaz . 

Una clase puede realizar mas de una interfaz, y una interfaz puede ser realizada por mas 
de una clase. 

Visibilidad 

El concepto de visibilidad esta muy relacionado con las interfaces y la reali- 
zacion. La visibilidad se aplica a atributos u operaciones, y establece la pro- 
portion en que otras clases podran utilizar los atributos y operaciones de una clase dada 
(o en operaciones de una interfaz). Existen tres niveles de visibilidad: Nivel publico , en el 
cual la funcionalidad se extiende a otras clases. En el nivel protegido la funcionalidad 
se otorga solo a las clases que se heredan de la clase original. En el nivel privado solo la 
clase original puede utilizar el atributo u operacion. En una television, modificarVolumen() 
y cambiarCanalO son operaciones publicas, en tanto que dibujarImagenEnPantalla() es 
privada. En un automovil, acelerar() y frenar() son operaciones publicas, pero 
actualizarKilometraje() o actualizarMillaje() es protegida. 

La realizacion, como podrfa imaginar, implica que el nivel publico se aplique a cualquier 
operacion en una interfaz. La protection de operaciones mediante cualquiera de los otros 
niveles tal vez no tendrfa sentido, dado que una interfaz se orienta a ser realizada por 
diversas clases. 

Para indicar el nivel publico, anteceda el atributo u operacion con un signo de suma (+), para 
revelar un nivel protegido, antecedalo con un simbolo de numero (#), y para indicar el nivel 
privado, antecedalo con un guion (-). La figura 5.8 muestra los atributos y operaciones publi- 
cos, protegidos y privados tanto en una television como en un automovil. 
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MaquinaDeEscribir 








Figura 5.8 

Los atributos y opera- 
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Ambito 

El ambito es otro concepto referente a los atributos y operaciones, y la forma 
en que se relacionan dentro de un sistema. Hay dos tipos de ambitos, el de 
instancia y el de archivador. En el primero cada instancia cuenta con su propio valor en 
un atributo u operacion. En un ambito de archivado , solo habra un valor del atributo u 
operacion en todas las instancias de la clase. Un atributo u operacion con el Ambito de 
archivador, aparece con su nombre subrayado. Este tipo de ambito se utiliza con frecuen- 
cia cuando un grupo especifico de instancias (ningunas otras) tienen que compartir los 
valores exactos de un atributo privado. El ambito de instancia es, por mucho, el tipo mas 
comun de ambito. 
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Resumen 

Para completar sus nociones de clases y la forma en que se conectan, es necesario com- 
prender algunas relaciones adicionales. Una agregacion establece una asociacion para 
conformar un todo: una clase “todo” se genera de clases que la componen. Un compo- 
nente en una agregacion puede ser parte de mas de un todo. Una composicion es una 
conformacion muy intimamente ligada con la agregacion en el sentido de que un compo- 
nente de una composicion puede ser parte solamente de un todo. La representacion del 
UML de las agregaciones es similar a la representacion de las composiciones. La linea 
de asociacion que une la parte con un todo tiene un rombo. En una agregacion, el rombo 
no esta relleno, en tanto que en una composicion si lo esta. 

Un diagrama de contexto enfoca la atencion en una clase especifica dentro de un sis- 
tema. Un diagrama de contexto de composicion es como un mapa detallado de un mapa 
mayor. Muestra un diagrama de clases anidado dentro de un gran simbolo rectangular de 
clase. Un diagrama de contexto de sistema muestra la forma en que el diagrama de clases 
compuestas se relaciona con otros objetos del sistema. 

Una realizacion es una asociacion entre una clase y una interfaz, una coleccion de opera- 
ciones que cierta cantidad de clases podra utilizar. Una interfaz se representa como una 
clase sin atributos. Para distinguirla de una clase cuyos atributos hay an sido omitidos del 
diagrama, el estereotipo «interfaz» aparecera por encima del nombre de la interfaz. Otra 
posibilidad es la de anteceder el nombre de la interfaz con una “I” mayuscula. La reali- 
zacion se representa en el UML mediante una linea discontinua con una punta de flecha 
en forma de triangulo sin rellenar que conecta a la clase con la interfaz. Otra forma para 
representar una realizacion es con una linea continua que conecte a una clase con un 
pequeno circulo, para que el cfrculo se interprete como la interfaz. 






En terminos de visibilidad, todas las operaciones en una interfaz son publicas , de modo 
que cualquier clase podra utilizarlas. Los otros dos niveles de visibilidad son protegido 
(la funcionalidad se extiende a las clases secundarias de aquella que contiene los atribu- 
tos y operaciones) y privado (atributos y operaciones que se pueden utilizar solo dentro 
de la clase que los contiene). Un signo de suma (+) denota a la visibilidad publica, el 
simbolo de numero (#) la protegida y el guion (-) la privada. 

El ambito es otro aspecto de los atributos y operaciones. En un ambito de instancia, cada 
objeto de una clase cuenta con su propio valor en un atributo u operacion. En un ambito 
de archivador, solo hay un valor para un atributo u operacion en particular a traves de un 
conjunto de objetos de una clase. Los objetos que no esten en este conjunto no podran 
acceder al valor contenido en el ambito de archivador. 

Preguntas y respuestas 

P ^Se considera transitiva a la agregacion? Es decir, si la clase 3 es un compo- 
nente de la clase 2, y la clase 2 es un componente de la clase 1, £la clase 3 sera 
un componente de la clase 1? 

R Asi es, la agregacion es transitiva. En nuestro ejemplo, los botones y la bola del 
raton son parte del raton, a la vez que son parte de la computadora. 

P ^La palabra “interfaz” implica “interfaz de usuario” o GUI? 

R No. Es algo mas generico. Una interfaz es tan solo un conjunto de operaciones que 
una clase presenta a las demas clases. De hecho, una de estas operaciones podria 
ser (aunque no necesariamente) la del usuario. 



Taller 

El cuestionario y los ejercicios verificaran y fortaleceran su conocimiento respecto al 
tema de las agregaciones, composiciones, contextos e interfaces. Las respuestas las podra 
ver en el Apendice A, “Respuestas a los cuestionarios”. 

Cuestionario 

1. ^Cual es la diferencia entre una agregacion y una composicion? 

2. ^Que es la realizacion? 

3. Mencione los tres niveles de visibilidad y describa lo que significa cada uno de 
ellos. 

Ejercicios 

1. Cree un diagrama de contexto de composicion de una revista. Tome en cuenta la 
tabla de contenido, la editorial, los articulos y las columnas. Luego, cree un dia- 
grama de contexto del sistema que muestre a la revista junto con el suscriptor y el 
comprador en el puesto de revistas. 




2. En la actualidad, el tipo mas popular de GUI es la interfaz WIMP (ventanas, iconos, 
menus y puntero, por sus siglas en ingles). Dibuje un diagrama de clases de la 
interfaz WIMP, y haga uso de todo el conocimiento adecuado del UML que ha 
adquirido hasta ahora. Ademas de las clases indicadas en las siglas, incluya los ele- 
mentos relacionados como las barras de desplazamiento y el cursor, asi como 
cualquiera de las otras clases necesarias. 



Hora 





Introduccion a los casos 
de uso 

Ahora que ha visto lo correspondiente a las clases y sus relaciones, es el 
momento de volver nuestra atencion a otra area principal del UML: los 
casos de uso. 

En esta hora se trataran los siguientes temas: 

• Que son los casos de uso 

• Importancia de los casos de uso 

• Inclusion de los casos de uso 

• Extension de los casos de uso 

• Inicio de un analisis de un caso de uso 

En las tres horas anteriores hemos visto los diagramas que proporcionan una 
idea estatica de las clases en un sistema. Ahora veremos a los diagramas que 
establecen una idea dinamica y mostraremos la forma en que el sistema y 
sus clases cambian con el tiempo. Las ideas estaticas ayudan a que un 
analista se comunique con un cliente. La idea dinamica, como vera, ayudara 
al analista a comunicarse con un grupo de desarrolladores, y ayudara a estos 
ultimos a crear programas. 



El cliente y el equipo de desarrollo conforman un importante conjunto de integrantes en 
un sistema. No obstante, una parte de igual importancia no se ha tornado en cuenta: el 
usuario. Ni la idea estatica ni la dinamica mostraran el comportamiento del sistema desde 
el punto de vista del usuario. Comprender tal punto de vista es clave para generar sistemas 
que sean tanto utiles como funcionales; esto es, que cumplan con los requerimientos y que 
sea facil (e, incluso, divertido) trabajar con ellos. 

El modelado de un sistema desde el punto de vista de un usuario es el trabajo de los casos 
de uso. En esta hora comprendera todo lo relacionado con los casos de uso y su funcion. 
En la siguiente hora aprendera a utilizar el diagrama de casos de uso del UML para 
visualizar un caso de uso. 

Que son los casos de uso 

Recientemente adquirf una maquina de fax. Cuando fui a comprarla, en un almacen de 
venta de equipo para oficinas, encontre una enorme gama de opciones. ^Como hice para 
decidirme por una en particular? Me pregunte exactamente que es lo que deseaba hacer 
con una maquina de fax. ^Que caracteristicas deseaba? ^Cuales funciones necesitaba que 
tuviera? ^Deseaba utilizar papel comun o termico? ^Queria generar copias? ^Conectarlo 
a mi computadora? ^Utilizarlo como digitalizador? ^Tendria que enviar faxes a tal 
velocidad que necesitaria una funcion de marcado rapido? ^Querria utilizar la maquina 
de fax para diferenciar entre una llamada telefonica y un fax entrante? 

Todos seguimos un procedimiento como este cuando realizamos una compra que no sea 
impulsiva. Lo que hacemos es seguir un tipo de analisis del caso de uso : nos preguntamos 
como utilizaremos el producto o sistema que queremos comprar, de modo que podamos 
obtener algo que cumpla con nuestras necesidades. Lo importante es saber cuales son 
esos requerimientos. 

Este tipo de analisis es particularmente crucial para la fase de analisis del desarrollo de 
un sistema. La forma en que los usuarios utilicen un sistema le da la pauta para lo que 
disenara y creara. 

El caso de uso es una estructura que ayuda a los analistas a trabajar con los usuarios para 
determinar la forma en que se usara un sistema. Con una coleccion de casos de uso se 
puede hacer el bosquejo de un sistema en terminos de lo que los usuarios intenten hacer 
con el. 



Imaginese al caso de uso como una coleccion de situaciones respecto al uso 
de un sistema. Cada escenario describe una secuencia de eventos. Cada 
secuencia se inicia por una persona, otro sistema, una parte del hardware o por el paso 
del tiempo. A las entidades que inician secuencias se les conoce como adores. El resul- 
tado de la secuencia debe ser algo utilizable ya sea por el actor que la inicio, o por otro 
actor. 
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Importancia de los casos de uso 

Asi como el diagrama de clases es un buen medio para estimular a un cliente a que hable 
respecto a un sistema desde su propio punto de vista, el caso de uso es una excelente 
herramienta para estimular a que los usuarios potenciales hablen, de un sistema, desde 
sus propios puntos de vista. No siempre es facil para los usuarios explicar como preten- 
den utilizar un sistema. Puesto que el desarrollo tradicional de los sistemas era, con fre- 
cuencia, algo asi como una ciencia oculta, con muy poca informacion para los usuarios, a 
aquellos que osaban preguntar se les daba informacion muy poco explicita o ciertamente 
confusa respecto a lo que utilizarfan. 

La idea es involucrar a los usuarios en las etapas iniciales del analisis y diseno del sis- 
tema. Esto aumenta la probabilidad de que el sistema sea de mayor provecho para la 
gente a la que supuestamente ayudara, en lugar de ser un manojo de expresiones de 
computation incomprensibles e inmanejables por los usuarios finales. 

Un ejemplo: la maquina de gaseosas 

Suponga que empezara a disenar una maquina despachadora de gaseosas. Para obtener el 
punto de vista del interesado, entrevistard a varios usuarios potenciales respecto a la 
manera en que utilizaran dicha maquina. 

Dado que la funcion principal de una maquina de gaseosas es permitir a un cliente adqui- 
rir una lata de gaseosa, probablemente las personas le diran que se enfrentara a diversos 
escenarios — un caso de uso, en otras palabras — que podrfa etiquetar como “Comprar 
gaseosa”. Examinemos cada posible escenario en este caso de uso. Recuerde que tales 
escenarios podrfan aparecer durante la conversation con los usuarios. 

Figura 6.1 
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El caso de uso "Comprar gaseosa" 

El actor, en este caso de uso, es un cliente que desea comprar una lata de gaseosa. El 
escenario iniciara cuando el cliente inserte dinero, posteriormente realizara una selec- 
cion; y si todo funciona bien, la maquina contara con, al menos, una lata de la gaseosa 
elegida, misma que pondra al alcance del cliente. 

Ademas de la secuencia, hay otros aspectos del escenario anterior que merecen cierta 
consideracidn. ^Que condiciones llevaron al cliente a iniciar el escenario en el caso de 
uso “Comprar gaseosa”? La sed es la mas obvia. ^Que se obtiene como resultado de tal 
escenario? Nuevamente, lo obvio es que el cliente tenga una gaseosa en su poder. 

^Lo que he descrito es la unica posibilidad de “Comprar gaseosa”? Habria otras cues- 
tiones que saltarian a la vista; por ejemplo, es posible que la maquina no tenga la gaseosa 
que desee el cliente; tambien es posible que el cliente no tenga el importe exacto de la 
gaseosa. ^Como disenaria a la maquina de gaseosas para controlar tales escenarios? 

Veamos el caso en que la maquina se haya quedado sin gaseosa, otra secuencia de pasos 
en el caso de uso “Comprar gaseosa”. Imagfnelo como una ruta altemativa dentro del 
caso de uso. El cliente inicia el caso de uso al insertar dinero en la maquina y posterior- 
mente hace una seleccion. La maquina no cuenta con ninguna lata de la gaseosa sele- 
ccionada, por lo que mostrara un mensaje al cliente que indicara que no tiene de 
esa marca. Lo ideal seria que el mensaje le pida al cliente que haga otra seleccion. La 
maquina tambien deberia dar la opcion de devolver el dinero al cliente. En este punto, 
el cliente selecciona otra marca que la maquina entregara (siempre y cuando cuente con 
provisiones de esta marca), o devolvera el dinero. La condicion previa es un cliente 
sediento y el resultado es una lata de gaseosa o la devolution del dinero. 




Claro que el escenario de quedarse sin gaseosa seria posible: el mensaje 
"No hay de esta marca" podria aparecer en cuanto las provisiones de la 
maquina se acabaran y permanecer a la vista hasta que la maquina sea 
reabastecida. En tal caso, el usuario podria no insertar el dinero en primera 
instancia. El cliente para el que usted disenara la maquina podria preferir 
el primer escenario: si el cliente ya inserto dinero, la tendencia podria ser 
hacer otra seleccion en lugar de pedir a la maquina que lo devuelva. 



Analicemos ahora el escenario de la cantidad de dinero incorrecta. Nuevamente, el 
usuario inicia el caso de uso en la forma usual y posteriormente hace una seleccion. 
Asumamos que la maquina tiene provision de la marca elegida. En la maquina hay una 
reserva de moneda fraccionaria y devuelve la diferencia al despachar la gaseosa. Si la 




maquina no cuenta con una reserva de moneda fraceionaria, devolvera el dinero y 
mostrara un mensaje que pida al usuario el importe exacto. La condicion previa es la 
ya indicada. El resultado sera una lata de gaseosa junto con el cambio, o la devolution 
del dinero originalmente depositado. 

Otra posibilidad es que tan pronto como se agote la moneda fraceionaria, aparezea un 
mensaje que informe a los clientes que se requiere el importe exacto. El mensaje per- 
manecerfa a la vista hasta que la maquina sea reabastecida con moneda fraceionaria. 

Casos de uso adicionales 

Ya ha examinado a la maquina de gaseosas desde el punto de vista de un usuario: el 
cliente. Hay otros usuarios que intervienen, como el proveedor que tiene que reabastecer 
a la maquina, el recolector de dinero (que tal vez sea el mismo que el proveedor) que 
tiene que recoger el dinero acumulado en la alcancia de la maquina, etcetera. Esto nos in- 
dica que debemos crear al menos dos casos de uso: “Reabastecer” y “Recolectar dinero”, 
cuyos detalles surgiran durante las entrevistas con los proveedores y los recolectores. 

Veamos el caso de uso de “Reabastecer”. El proveedor inicia este caso de uso dado que 
algun intervalo (digamos, dos semanas) ha pasado. El representante del proveedor le 
quita el seguro a la maquina (tal vez mediante una Have y un cerrojo, pero eso entra den- 
tro de la implementation), jala la puerta para abrir la maquina, y llena el compartimiento 
de cada marca hasta su capacidad. El representante tambien rellena la reserva de moneda 
fraceionaria. Luego, cierra el frente de la maquina y vuelve a poner el seguro. La condi- 
cion previa es el paso del intervalo, el resultado es que el proveedor cuenta con un nuevo 
conjunto de ventas potenciales. 

Para el caso de uso de “Recolectar el dinero”, el recolector inicia debido tambien a que 
ha pasado cierto tiempo. La persona debera seguir la misma secuencia que en “Reabas- 
tecer” para abrir la maquina. El recolector sacara el dinero de la maquina y seguira los 
pasos de “Reabastecer” para cerrar y poner el seguro a la maquina. La condicion previa 
es el paso del intervalo y el resultado es el dinero en las manos del recolector. 

Vea que cuando derivamos un caso de uso, no nos preocupamos por la forma de imple- 
mentarlo. En nuestro ejemplo, no nos interesamos en los aspectos intemos de la maquina 
de gaseosas. Tampoco por la forma en que funcione el mecanismo de refrigeration, o 
por la forma en que la maquina controle la cantidad de dinero que contenga. Tan solo 
intentamos ver la forma en que la maquina lucira para alguien que tenga que utilizarla. 

El objetivo es derivar una coleccion de casos de uso que, finalmente, mostraremos a las 
personas que disenen la maquina de gaseosas y a las personas que la construiran. Por 
anadidura, nuestros casos de uso reflejan lo que los clientes, recolectores y proveedores 
desean, por lo que el resultado sera una maquina que todos esos grupos puedan utilizar 
con facilidad. 




Inclusion de los casos de uso 

En los casos de uso “Reabastecer” y “Recolectar dinero”, tal vez distinguio ciertos pasos 
en comun. Ambos empezaban con abrir la maquina, y finalizaban con el cierre de la 
maquina y su aseguramiento. ^Podnamos eliminar la duplicacion de pasos de un caso 
de uso al otro? 

Si podemos. La forma de hacerlo es tomar cada secuencia de pasos en comun y confor- 
mar un caso de uso adicional a partir de ellos. Combinemos los pasos necesarios para 
“quitar el seguro” y “abrir la maquina” y llamemoslos “Exhibir el interior” y los pasos 
“cerrar la maquina” y “asegurarla” en otro caso de uso llamado “Cubrir el interior”. 

Con estos nuevos casos de uso a la mano, el caso de uso “Reabastecer” iniciarfa con 
el caso de uso “Exhibir el interior”. Luego, el representante del proveedor seguirfa los 
pasos ya indicados, y concluirfa con el caso de uso “Cubrir el interior”. De forma similar, 
el caso de uso “Recolectar dinero” iniciarfa con “Exhibir el interior”, procederfa como 
se indico, y finalizaria con el caso de uso “Cubrir el interior”. 

Como ve, “Reabastecer” y “Recolectar dinero” incluyen los nuevos casos de uso. Por 
ello, a esta tecnica de aprovechamiento de un caso de uso se le conoce como inclusion 
de un caso de uso. 




La inclusion de un caso de uso tambien se conoce como usar un caso de uso . 
Creo que el termino incluir tiene dos ventajas. La primera, es mas clara: los 
pasos en un caso de uso, incluyen los de otro. La segunda, se evita la con- 
fusion potencial de las palabras "usar" y "uso" en un contexto tan estrecho. 
As i, no tendremos que decir "promover el uso mediante el uso reiterativo de 
un caso de uso". 



Extension de los casos de uso 

Es posible volver a utilizar un caso de uso de una forma distinta a una inclusion. En oca- 
siones crearemos un caso de uso agregandole algunos pasos a un caso de uso existente. 

Regresemos al caso de uso “Reabastecer”. Antes de colocar nuevas latas de gaseosas 
en la maquina, suponga que el representante del proveedor nota las marcas que se han 
vendido bien, asi como las que no se han vendido tan bien. En lugar de solo reabastecer 
todas las marcas, el representante podrfa sacar aquellas que no se han vendido bien, y 
reemplazarlas por latas de las marcas que han probado ser mas populares. De esta forma, 
tendrfa que indicar al frente de la maquina el nuevo surtido de marcas disponibles. 

Si agregamos estos pasos a “Reabastecer”, tendremos un nuevo caso de uso que llama- 
riamos “Reabastecer de acuerdo a las ventas”. Este nuevo caso de uso es una extension 
del original, accion a la que se le conoce como extension de un caso de uso. 





Inicio del analisis de un caso de uso 

En nuestro caso, nos hemos involucrado directamente con los casos de uso y nos hemos 
enfocado en algunos de ellos. En el mundo real, por lo general, seguira un conjunto de 
procedimientos cuando empiece un analisis de casos de uso. 

Empezara con entrevistas a los clientes (y entrevistas con expertos) que lo lleven a los 
diagramas iniciales de clases que indicamos en la hora 3. Esto le dara cierta idea del area 
en la que trabajara y una familiaridad con los terminos que utilizara. Posteriormente, 
contara con un fundamento para hablar con los usuarios. 

Entrevistara a los usuarios (preferentemente en grupos) y les pedira que le indiquen todo 
lo que ellos hanan con el sistema que usted disenara. Sus respuestas conformaran un 
conjunto candidato de casos de uso. Luego, es importante describir brevemente cada caso 
de uso. Tambien tendra que derivar una lista de todos los actores que iniciaran 
y se beneficiaran de los casos de uso. Cuenta mas informacion obtenga en esta fase, 
aumentara su aptitud para hablar con los usuarios en su propio idioma. 

Los casos de uso apareceran en varias fases del proceso de desarrollo. Le ayudaran con 
el diseno de una interfaz del usuario, coadyuvaran con las opciones de desarrollo de los 
programadores y estableceran las bases para probar el sistema recien generado. 

Para mayor informacion en el tema del analisis de los casos de uso, va a tener que aplicar 
el UML, y ello se hara en la siguiente hora. 



Resumen 

El caso de uso es una estructura para describir la forma en que un sistema lucira para los 
usuarios potenciales. Es una coleccion de escenarios iniciados por una entidad llamada 
actor (una persona, un componente de hardware, un lapso u otro sistema). Un caso de 
uso deberfa dar por resultado algo de valor ya sea para el actor que lo inicio o para otro. 

Es posible volver a utilizar casos de uso. Una forma (“inclusion”) es utilizar los pasos 
de un caso de uso como parte de la secuencia de pasos de otro caso de uso. Otra forma 
(“extension”) es crear un nuevo caso de uso mediante la adicion de pasos a un caso de 
uso existente. 

La entrevista directa con los usuarios es la mejor tecnica para derivar casos de uso. 
Cuando se deriva un caso de uso, es importante destacar las condiciones para iniciar 
el caso de uso, y los resultados obtenidos como consecuencia del mismo. 

Hara las entrevistas a los usuarios despues de entrevistar a los clientes y generar una lista 
de prospectos de clases. Esto le dara un fundamento en la terminologia que utilizara para 
hablar con los usuarios. Es una buena idea entrevistar a un grupo de usuarios. El objetivo 
es derivar un conjunto candidato de casos de uso y todos los posibles actores. 



Preguntas y respuestas 

P En realidad ip ara que necesito el concepto del caso de uso? ^Que no solo 
podriamos preguntar a los usuarios lo que deseen ver en el sistema y dejarlo 
asi? 

R En realidad, no. Tenemos que crear una estructura de lo que los usuarios nos digan, 
y los casos de uso la proporcionan. La estructura se vuelve util cuando tiene que 
llevar los resultados de sus entrevistas con los usuarios y comunicarlos a los 
clientes y desarrolladores. 

P ^Que tan dificil es derivar los casos de uso? 

R De acuerdo con mi experiencia, el listado de casos de uso — al menos los de alto 
nivel— no es muy complejo. Hay ciertas dificultades al profundizar en cada una 
e intentar lograr que los usuarios listen los pasos de cada escenario. Cuando genere 
un sistema que reemplace una manera existente de hacer las cosas, los usuarios 
tipicamente ya sabran los pasos bastante bien y los habran utilizado con tanta 
regularidad que se les dificultara estructurarlos. Es una buena idea tener un panel 
de usuarios, ya que la discusion en grupo por lo general trae consigo ideas que 
un usuario en particular podrfa tener problemas para expresar. 



Taller 

Esta hora se baso en teorfa mas que en el UML. En este taller, el objetivo sera compren- 
der los conceptos teoricos y aplicarlos en diversos contextos. La practica, que veremos 
en la siguiente hora, le ayudara a reafirmar los conceptos cuando aprenda a visualizarlos 
mediante el UML. Las respuestas aparecen en el Apendice A, “Respuestas a los cues- 
tionarios”. 

Cuestionario 

1. ^Como se llama a la entidad que inicia un caso de uso? 

2. ^Que se entiende con “incluir un caso de uso”? 

3. ^Que se entiende con “extender un caso de uso”? 

4. ^Un caso de uso es lo mismo que un escenario? 

Ejercicios 

1 . En el caso del ejemplo de la maquina de gaseosas, cree otro caso de uso que 
incluya a los casos de uso “Exhibir el interior” y “Cubrir el interior”. 

2. Los casos de uso pueden ayudarle a analizar un negocio y un sistema. Imagine a 
una gran tienda de equipos de computo que venda hardware, perifericos y software. 
^Quienes serfan los actores? ^Cuales serfan algunos de los principales casos de 
uso? ^Cuales serfan algunos de los escenarios dentro de cada caso de uso? 




Hora 7 



Diagramas de casos de uso 

El caso de uso es un poderoso concepto que ayuda a un analista a compren- 
der la forma en que un sistema debera comportarse. Le ayuda a obtener los 
requerimientos desde el punto de vista del usuario. Es necesario aprender a 
visualizar los conceptos del caso de uso que conocio en la hora anterior. 

En esta hora se trataran los siguientes temas: 

• Representacion de un modelo de caso de uso 

• Concepcion de las relaciones entre casos de uso 

• Diagramas de casos de uso en el proceso de analisis 

• Aplicacion de los modelos de caso de uso 

• Vera la idea general del UML 

El caso de uso es muy poderoso, pero lo es aun mas cuando se visualiza 
por medio del UML. Esta visualization le permitira mostrar los casos de uso 
a los usuarios para que ellos le puedan dar mayor information. Es un hecho 
que los usuarios con frecuencia saben mas de lo que dicen: el caso 
de uso ayuda a romper el hielo. A su vez, una representacion visual le ayuda 
a combinar los diagramas de casos de uso con otro tipo de diagramas. 

Una de las finalidades del proceso de analisis de un sistema es generar una 
coleccion de casos de uso. La idea es tener la posibilidad de catalogar y 



hacer referencia a esta coleccion, que sirve como el punto de vista de los usuarios acerca 
del sistema. Cuando llegue el momento de actualizar el sistema, el catalogo de casos de 
uso funcionara como un fundamento para obtener los requerimientos de la actualization. 



Representacion de un modelo 
de caso de uso 

Hay un actor que inicia un caso de uso y otro (posiblemente el que initio, pero no nece- 
sariamente) que recibira algo de valor de el. La representacion grafica es directa. Una 
elipse representa a un caso de uso, una figura agregada representa a un actor. El actor 
que inicia se encuentra a la izquierda del caso de uso, y el que recibe a la derecha. El 
nombre del actor aparece justo debajo de el, y el nombre del caso de uso aparece ya sea 
dentro de la elipse o justo debajo de ella. Una lfnea asociativa conecta a un actor con el 
caso de uso, y representa la comunicacion entre el actor y el caso de uso. La lfnea aso- 
ciativa es solida, como la que conecta a las clases asociadas. 

Uno de los beneficios del analisis del caso de uso es que le muestra los confines entre el 
sistema y el mundo exterior. Generalmente, los actores estan fuera del sistema, mientras 
que los casos de uso estan dentro de el. Utilizara un rectangulo (con el nombre del sis- 
tema en algun lugar dentro de el) para representar el conffn del sistema. El rectangulo 
envuelve a los casos de uso del sistema. 

Los actores, casos de uso y lfneas de interconexion componen un modelo de 
caso de uso. La figura 7.1 le muestra estos sfmbolos. 



Termino Nuevo 



Figura 7.1 

En un modelo de caso 
de uso , una figura 
agregada representa a 
un actor, una elipse 
a un caso de uso y una 
linea asociativa repre- 
senta la comunicacion 
entre el actor y el caso 
de uso. 




Una nueva visita a la maquina de gaseosas 

Apliquemos los sfmbolos al ejemplo de la hora anterior. Como recuerda, desarrollo 
los casos de uso para una maquina de gaseosas. El caso de uso “Comprar gaseosa” se 
encuentra dentro del sistema junto con “Reabastecer” y “Recolectar dinero”. Los actores 
son el Cliente, Representante del proveedor y el Recolector. La figura 7.2 le muestra un 
modelo UML de caso de uso para una maquina de gaseosas. 




Figura 7.2 

Un modelo de caso de 
uso proveniente de la 
maquina de gaseosas 
de la hora 6. 




Secuencia de pasos en los escenarios 

Cada caso de uso es una coleccion de escenarios y cada escenario es una secuencia de 
pasos. Como puede ver, tales pasos no aparecen en el diagrama. No se encuentran en 
notas adjuntas a los casos de uso. Aunque el UML no lo prohibe, la claridad es clave 
en la generacion de cualquier diagrama y el adjuntar notas a cada caso de uso podrfa 
volverlo confuso. ^Como y donde haria la secuencia de pasos? 

El uso de los diagramas de casos de uso sera, por lo general, parte de un documento 
de diseno que el cliente y el equipo de diseno tomaran como referenda. Cada diagrama 
tendra su propia pagina, de igual manera, cada escenario de caso de uso tendra su propia 
pagina, donde se listara en modo de texto a: 

El actor que inicia al caso de uso 

Condiciones previas para el caso de uso 

Pasos en el escenario 

Condiciones posteriores cuando se finaliza el escenario 
El actor que se beneficia del caso de uso 

Tambien puede enumerar las conjeturas del escenario (por ejemplo, que un cliente 
a la vez utilizara la maquina de gaseosas) y una breve description de una sola frase 
del escenario. 







La hora 6, “Introduccion a los casos de uso”, presento algunos escenarios alternatives del 
caso de uso “Comprar gaseosa”. En su description, tambien podria poner estos 
escenarios de manera separada (“Sin el producto” y “Cambio incorrecto”), o podria 
considerarlos como excepciones al primer escenario del caso de uso. La forma exacta 
de hacerlo solo le concemira a usted, su cliente y los usuarios. 



Para mostrar los pasos en un escenario, hay otra posibilidad que es utilizar 
un diagrama de actividades UML sobre el cual hablaremos en la hora 11, 
"Diagramas de actividades". 




Concepcion de las relaciones entre 
casos de uso 



Termino Nuevo 



El ejemplo de la hora 6 tambien mostro dos formas en que los casos de uso 
se pueden relacionar entre si. Una de ellas, la inclusion , le permite volver a 
utilizar los pasos de un caso de uso dentro de otro. La otra, extension , le permite crear 
un caso de uso mediante la adicion de pasos a uno existente. 



Termino Nuevo 



Existen otros dos tipos de relaciones que son generalizacion y agrupamiento. 
Como en las clases, la generalizacion cuenta con un caso de uso que se 
hereda de otro. El agrupamiento es una manera sencilla de organizar los casos de uso. 



Inclusion 

Examinemos los casos de uso “Reabastecer” y “Reeolectar dinero” del ejemplo de la 
hora 6. Ambos se inician mediante la apertura de la maquina, y finalizan con el cierre 
y sellado de la misma. El caso de uso “Exhibir el interior” se creo para capturar el primer 
par de pasos; y “Cubrir el interior” para el segundo. Tanto “Reabastecer”, como 
“Reeolectar dinero” incluyen este par de casos de uso. 

Para representar a la inclusion utilizara el simbolo que uso para la dependencia entre 
clases: una linea discontinua con una punta de flecha que conecta las clases apuntando 
hacia la clase dependiente. Justo sobre la linea, agregara un estereotipo: la palabra 
“incluir” bordeada por dos pares de parentesis angulares. La figura 7.3 le muestra la 
relation de «inclusion» en el modelo de caso de uso de la maquina de gaseosas. 




Tenga en cuenta que un caso de uso incluido nunca aparecera solo. 
Simplemente funciona como parte de un caso de uso que lo incluya. 



En la notation de texto que sigue los pasos en la secuencia, indicara los casos de uso 
incluidos. El primer paso en el caso de uso “Reabastecer” podria ser «incluir» (Exhibir 
el interior). 








Figura 7.3 

El modelo de caso de 
uso en la maquina 
de gaseosas con 
la inclusion. 




Extension 

La hora 6 mostro que el caso de uso “Reabastecer” podrfa ser la base de otro 
caso de uso: “Reabastecer de acuerdo a las ventas”. En lugar de solo reabas- 
tecer la maquina de gaseosas para que todas las marcas tengan la misma cantidad 
de latas, el representante podrfa anotar aquellas que se venden mejor y reabastecer acorde 
con ello. Por lo que podemos decir que el nuevo caso de uso extiende al original dado que 
agrega otros pasos a la secuencia del caso de uso original, que se conoce como el caso 
de uso base. 



Termino Nuevo 
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La extension solo se puede realizar en puntos indicados de manera especifica 
dentro de la secuencia del caso de uso base. A estos puntos se les conoce 
como puntos de extension. En el caso de uso Reabastecer, los nuevos pasos (anotar 
las ventas y abastecer de manera acorde) se darfan luego que el representante haya 
abierto la maquina y este listo para llenar los compartimientos de las marcas de gaseosas. 
En este ejemplo, el punto de extension es “Llenar los compartimientos”. 



Como la inclusion, podra concebir la extension con una lmea de dependencia (linea 
discontinua con punta una punta de flecha), junto con un estereotipo que muestra 
“extender” entre parentesis angulares. Dentro del caso de uso basico, el punto de extension 
aparecera debajo del nombre del caso de uso. La figura 7.4 le muestra la relation de 
extension para “Reabastecer” y “Reabastecer de acuerdo a las ventas”, junto con la 
inclusion de relaciones para “Reabastecer” y “Recolectar dinero”. 





Figura 7.4 

Un diagrama de casos 
de uso que muestra 
la extension y la 
inclusion. 




Generalization 

Las clases pueden heredarse entre si y esto tambien se aplica a los casos de uso. En la 
herencia de los casos de uso, el caso de uso secundario hereda las acciones y significado 
del primario, y ademas agrega sus propias acciones. Puede aplicar el caso de uso secun- 
dario en cualquier lugar donde aplique el primario. 

En el ejemplo, debera imaginar un caso de uso “Comprar un vaso de gaseosa” que se 
hereda de “Comprar gaseosa”. El caso de uso secundario tiene acciones como “agregar 
hielo” y “mezclar marcas de gaseosas”. Modelara la generalizacion de casos de uso 
de la misma forma que lo hace con las clases: con lfneas continuas y una punta de flecha 
en forma de tri&ngulo sin rellenar que apunta hacia el caso de uso primario, como se 
muestra en la figura 7.5. 

Figura 7.5 

Un caso de uso puede 
heredar el sentido y 
comportamiento de 
otro. 




La relacion de generalizacion puede establecerse entre actores, asi como entre casos de 
uso. Quiza tenga personificados al representante del proveedor, al recolector y al agente 
del proveedor. Si cambia el nombre del representante como Reabastecedor, tanto este 
como el Recolector seran secundarios del Agente Proveedor, como muestra la figura 7.6. 



Figura 7.6 

Como las clases 
y los casos de uso f 
los actores pueden 
estar en una relacion 
de generalizacion. 




Reabastecedor 



Recolector 




Agrupamiento 

En ciertos diagramas de casos de uso, podrfa tener varios casos de uso que querra organi- 
zar. Esto puede ocurrir cuando un sistema consta de varios subsistemas. Otra posibilidad 
serfa cuando entrevista a los usuarios para obtener los requerimientos de un sistema. Cada 
requerimiento podrfa ser representado como un caso de uso por separado. Necesitara 
alguna forma de ordenar los requerimientos por categorfas. 

La forma mas directa de organizar serfa agrupar en un paquete los casos de uso que se 
relacionen. Recuerde que un paquete aparece como una carpeta tabular. Los casos de uso 
agrupados apareceran dentro de la carpeta. 

Diagramas de casos de uso 
en el proceso de analisis 

Con el ejemplo dado y con el cual ha trabajado, aplico directamente la simbologfa 
del caso de uso. Ahora nos regresaremos un poco y colocaremos los casos de uso en 
el contexto de un esfuerzo de analisis. 

Las entrevistas al cliente deberan iniciar el proceso. Estas entrevistas produciran diagramas 
de clases que fungiran como las bases de su conocimiento para el dominio del sistema 
(el area en el cual resolvera los problemas). Una vez que conozca la terminologfa general 
del area del cliente, estara listo para hablar con los usuarios. 

Las entrevistas con los usuarios comienzan en la terminologfa del dominio, aunque 
deberan altemarse hacia la terminologfa de los usuarios. Los resultados iniciales de las 
entrevistas deberan revelar a los actores y casos de uso de alto nivel que describiran 
los requerimientos funcionales en terminos generales. Esta information establece los 
confines y ambito del sistema. 

Las entrevistas posteriores con los usuarios profundizaran en estos requerimientos, lo 
que dara por resultado modelos de casos de uso que mostraran los escenarios y las 
secuencias detalladamente. Esto podrfa resultar en otros casos de uso que satisfagan las 
relaciones de inclusion y extension. En esta fase, es importante confiar en su compren- 
sion del dominio (a partir de los diagramas de clases derivados de las entrevistas con el 
cliente). Si no comprende adecuadamente el dominio, podrfa crear demasiados casos de 
uso y demasiados detalles (situation que podrfa, definitivamente, obstaculizar el diseno 
y el desarrollo). 

Aplicacion de los modelos de caso de uso 

Para ayudarle a comprender con mas profundidad los modelos de casos de uso y como 
aplicarlos, vamos a ver un ejemplo mas complejo que una maquina de gaseosas. Suponga 
que debera disenar una red de area local (LAN) para una firma de consultorfa, 
y que tendra que comprender la funcionalidad para poder crearla. ^Como empezarfa? 





Una LAN es una red de comunicaciones que una organization utiliza en un 
ambito limitado. Permite a los usuarios compartir recursos e information. 



Comprension del dominio 

Empecemos con las entrevistas al cliente para crear un diagrama de clases que refleje 
como es la vida en el mundo de la consultona. El diagrama de clases podria incluir las 
siguientes clases: Consultor, Cliente, Proyecto, Propuesta, Datos e Informe. La figura 7.7 
le muestra la forma en que podna lucir el diagrama. 



Figura 7.7 

Un diagrama de clases 
para el mundo 
de la consultona . 




Comprension de los usuarios 

Ahora que el dominio esta a la mano, vuelva su atencion a los usuarios debido a que el 
objetivo sera entender los tipos de funcionalidad por crear en el sistema. 

En el mundo real, entrevistarfa a los usuarios. En este ejemplo, basara sus ideas en cierto 
conocimiento general de las LANs y del dominio. No obstante, tenga presente que en el 
analisis de sistemas del mundo real, nada puede sustituir a las entrevistas con las personas. 

Un grupo de usuarios seran consultores, otros podnan ser oficinistas. Entre otros usuarios 
en potencia se encontraran funcionarios corporativos, vendedores, administradores de 
red, administradores de oficina y administradores de proyectos. (^Se le ocurren otros?) 

En este punto, sena conveniente a mostrar a los usuarios en una jerarquia de generaliza- 
tion, como se observa en la figura 7.8. 

Comprension de los casos de uso 

^Que hay de los casos de uso? Hay algunas posibilidades: “Establecer niveles de seguri- 
dad”, “Crear una propuesta”, “Almacenar una propuesta”, “Utilizar correo electronico”, 
“Compartir informacion de la base de datos”, “Realizar la contabilidad”, “Conectarse a 
la LAN desde fuera de ella”, “Conectarse a Internet”, “Compartir informacion de la base 


















de datos”, “Indizar las propuestas”, “Utilizar propuestas previas” y “Compartir impreso- 
ras”. De acuerdo con esta informacion, la figura 7.9 le muestra el diagrama de casos de 
uso de alto nivel que hemos generado. 

Figura 7.8 

La jerarquia de 
usuarios que 
interactuaran 
con la LAN. 



Empleado 





Funcionario Administrador Consultor Oficinista 




Administrador Administrador Administrador 
de oficina de proyectos de la red 



Este conjunto de casos de uso constituye los requerimientos funcionales de la LAN. 

Profundizacion 

Elaboremos uno de los casos de uso de alto nivel y generemos un modelo de caso de uso. 
Una actividad extremadamente importante en una firma de consultorfa es la generation 
de propuestas, asf que examinemos el caso de uso “Crear una propuesta”. 

Las entrevistas con los consultores probablemente le indicaran cuantos pasos se necesitan 
en este caso de uso. Para empezar, el actor inicial es un consultor. El consultor tiene 
que iniciar una sesion en la LAN y ser verificado como usuario valido. Luego tendra que 
utilizar algun software integrado para oficina (procesador de textos, hoja de calculo y 
graficos) para escribir la propuesta. En el proceso, el consultor podrfa volver a utilizar 
porciones de propuestas previas. La firma de consultorfa podrfa tener una directiva de 
que un funcionario corporativo y otros dos consultores revisen una propuesta antes 
de que llegue a manos del cliente. Para ello, el consultor almacena la propuesta en un 
area central accesible mediante la LAN, y envfa a los correos electronicos de los tres revi- 
sores un mensaje que indique que la propuesta se encuentra lista, asf como su ubicacion. 



Luego de recibir los comentarios y hacer las modificaciones necesarias (nuevamente, 
con el software integrado para oficina), el consultor imprime la propuesta y la envia 
por correo al cliente. Cuando todo termina, el consultor se retira de la red. El consultor 
habra completado una propuesta y es el actor que se beneficia del caso de uso. 



Figura 7.9 

Un diagrama de casos 
de uso de alto nivel 
que representa una 
LAN para una firma 
de consultoria. 




Funcionario 

corporativo 




Administrator 
de oficina 




Administrador 
de proyecto 




Consultor 



Administrador 
de red 




Oficinista 






En la secuencia anterior, es claro que ciertos pasos se repetiran de un caso de uso a otro, 
y ello le llevara a otros casos de uso (posiblemente incluidos) en los que tal vez no habfa 
pensado. Iniciar una sesion y ser verificado son dos pasos que pueden incluir varios 
casos de uso. Por ello, creara un caso de uso “Verificar usuario” que incluya “Crear una 
propuesta”. Otro par de casos de uso son “Utilizar software de oficina” y “Finalizar sesion 
de la red”. 

Podrian aparecer otros detalles del proceso de una propuesta cuando vea que las propues- 
tas elaboradas para los clientes nuevos son diferentes a las de los clientes constantes. En 
si, las propuestas a los nuevos clientes probablemente incluyen informacion promocional 
de la empresa. Con los clientes constantes, no sera necesario enviar tal informacion. Asf 
pues, otro nuevo caso de uso, “Crear una propuesta para un cliente nuevo” extendera a 
“Crear una propuesta”. 

La figura 7. 10 le muestra el diagrama de casos de uso que resulta de este analisis del caso 
de uso “Crear una propuesta”. 



Figura 7.10 

El caso de uso “ Crear 
una propuesta ” en 
la LAN de una firma 
de consultoria. 




Este ejemplo aterriza un punto importante, uno que habfa destacado anteriormente: El 
analisis del caso de uso describe el comportamiento de un sistema. No toca a la imple- 
mentation. jEsto es particularmente importante en este caso, dado que el diseno de una 
LAN supera, por mucho, el alcance de este libro! 

Donde estamos 

Este es un buen momento para ver la estructura general del UML dado que ya ha avan- 
zado en dos de sus principales aspectos: la orientation a objetos y el analisis de casos de 
uso. Ha visto sus fundamentos y simbologfa, asf como explorado algunas aplicaciones. 




En las horas 2 a la 7 ha trabajado con: 



Clases 

Objetos 

Interfaces 

Casos de uso 

Actores 

Asociaciones 

Generalizaciones 

Realizaciones 



Agregaciones 

Composiciones 

Estereotipos 

Restricciones 

Notas 

Paquetes 

Extensiones 

Inclusiones 



Intentemos dividir este conjunto de elementos en categorfas. 

Elementos estructurales 

Las clases, objetos, actores, interfaces y casos de uso son cinco de los elementos es- 
tructurales en el UML. Aunque tienen diversas diferencias (mismas que, como ejercicio, 
debera indicar), son similares en el sentido de que representan partes ya sea fisicas o 
conceptuales de un modelo. Conforme avance en la parte 1, vera otros elementos 
estructurales. 



Relaciones 

La asociacion, generalization, dependencia y realization, son las relaciones en el UML. 
(La inclusion y extension son dos tipos de dependencias.) Sin las relaciones, los modelos 
UML no serfan mas que listas de elementos estructurales. Las relaciones conectan a tales 
elementos y de ese modo conectan los modelos con la realidad. 

Agrupamiento 

El paquete es el unico elemento de agrupamiento en el UML, este le permite organizar 
los elementos estructurales en un modelo. Un paquete puede contener cualquier tipo de 
elemento estructural, y diferentes tipos a la vez. 

Anotacion 

La nota es el elemento de anotacion del UML; estas le permiten adjuntar restricciones, 
comentarios, requerimientos y graficos explicativos a sus modelos. 




Extension 

Los estereotipos o clises son dos estructuras que el UML proporciona para extender el 
lenguaje. Le permiten crear nuevos elementos ademas de los existentes, de modo que 
pueda modelar de forma adecuada la seccion de realidad en la que se centrara su sistema. 

...y mas 

Ademas de los elementos estructurales, relaciones, agrupamientos, anotaciones y exten- 
siones, el UML cuenta con otra categorfa: elementos de comportamiento. Tales elementos 
le muestran la torma en que las partes de un modelo (como los objetos) cambian con el 
tiempo. Aun no sabe utilizarlos, pero los vera en la siguiente hora. 



El Panorama 

Ahora ya tiene una idea de la forma en que el UML se organiza. La figura 7. 1 1 esquema- 
tiza esta organizacion por usted. Conforme vea las siguientes horas de la parte I, tenga 
esta organizacion en mente. Le hara adiciones conforme avance y este “panorama” le 
mostrara donde agregar el nuevo conocimiento que adquiera. 



Figura 7.11 

La organizacion del 
UML , en terminos de 
los elementos que ha 
utilizado hasta ahora. 
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Resumen 

El caso de uso es una poderosa herramienta para obtener los requerimientos funcionales. 
Los diagramas de casos de uso agregan mayor poder: debido a que conciben los casos 
de uso, facilitan la comunicacion entre los analistas y los usuarios, y entre los analistas y 
los clientes. En un diagrama, el simbolo del caso de uso es una elipse. El simbolo de un 
actor es una figura adjunta. Una lfnea asociativa conecta a un actor con el caso de uso. 
Los casos de uso estan, por lo general, dentro de un rectangulo que representan el conffn 
del sistema. 

La inclusidn se representa por una lfnea de dependencia con un estereotipo «incluir». La 
extension se representa por una lfnea de dependencia con un estereotipo «extender». Las 
otras dos relaciones entre casos de uso son generalizacion, en la que un caso de uso here- 
da el sentido y acciones de otro, y el agrupamiento, mismo que organiza un conjunto de 
casos de uso. La generalizacion se representa por la misma lfnea que muestra la herencia 
entre clases. El agrupamiento se representa por el icono del paquete. 

Los diagramas de casos de uso figuran con fuerza en el proceso de analisis. Se empieza 
con entrevistas con los clientes para obtener diagramas de clases. Estos proporcionan una 
base para entrevistar a los usuarios. Tales entrevistas dan por resultado un diagrama de 
casos de uso de alto nivel que muestra los requerimientos funcionales del sistema. Para 
crear los modelos de caso de uso, profundice en cada caso de uso de alto nivel. Los dia- 
gramas resultantes de caso de uso daran los fundamentos para el diseno y desarrollo. 

Ahora que ha visto la orientacion a objetos y los casos de uso, esta listo para ver el pano- 
rama del UML. Los elementos que ha aprendido de las horas 2 a 7 se encuentran en estas 
categorfas: elementos estructurales, relaciones, organization, anotacion y extension. En la 
siguiente hora vera un elemento de la categorfa restante: elementos de comportamiento. 
Tenga en mente este panorama para que se le facilite el aprendizaje del UML. 

Preguntas y respuestas 

P Me di cuenta que en el diagrama de casos de uso de alto nivel no mostro las 
asociaciones entre los actores y los casos de uso. <,A que se debe? 

R El diagrama de casos de uso de alto nivel surge en las etapas iniciales de las entre- 
vistas con los usuarios. En este punto, esto es mas o menos un ejercicio de recopi- 
lacion de ideas y el objetivo es encontrar los requerimientos generates, ambito y 
confines del sistema. Las asociaciones tendran mayor sentido cuando posteriores 
entrevistas con los clientes le lleven a profundizar en cada requerimiento y que los 
modelos de casos de uso tomen forma. 




P ^Por que es importante tener en cuenta tal “panorama” del UML? ^No bastaria 
eou t\ue sepa utVUxar cada tipo de diagrama? 

R Si usted comprende la organization del UML, podra manejar situaciones que no 
haya encontrado antes. Podra reconocer cuando un elemento UML existente no haga 
el trabajo, y sabra como construir uno nuevo. Tambi6n sabra como crear un diagrama 
hibrido si llegara a ser la unica forma de presentar claramente un modelo. 



Taller 

En este taller continuara con el conocimiento obtenido en la hora 6 y lo usara como base 
para el conocimiento de la hora 7. El objetivo es utilizar su nuevo conocimiento para 
concebir los casos de uso y sus relaciones. Las respuestas aparecen en el Apendice A, 
“Respuestas a los cuestionarios”. 

Cuestionario 

1. Mencione dos ventajas de concebir un caso de uso. 

2. Describa la generalization y el agrupamiento, las relaciones entre los casos de uso 
que ha visto durante esta hora. Mencione dos situaciones en las que usted agruparfa 
los casos de uso. 

3. ^Cuales son las similitudes entre las clases y los casos de uso? ^Cuales las 
diferencias? 

Ejercicios 

L Bosqueje el diagrama de un modelo de caso de uso para un control remoto de una 
television. Asegurese de incluir todas las funciones del control remoto como casos 
de uso para su modelo. 

2. En el segundo ejercicio de la hora 6 indico a los actores y casos de uso de un al- 
macen de computo. Esta vez, dibuje un diagrama de casos de uso de alto nivel con 
base en el trabajo que realizo en tal ejercicio. Luego, genere un modelo de caso 
de uso para al menos uno de los casos de uso de alto nivel. En su trabajo, intente 
incorporar las relaciones «incluir» o «extender» que sean necesarias. 
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Diagramas de estados 

Hasta ahora ha comprendido los importantes elementos estructurales del 
UML. Ahora vera un elemento que le muestra c6mo modificar los procedi- 
mientos con el tiempo. 

En esta hora se trataran los siguientes temas: 

• Que es un diagrama de estados 

• Sucesos, acciones y condiciones de seguridad 

• Subestados: secuenciales y concurrentes 

• Estados historicos 

• Por que son importantes los diagramas de estados 

• Adicion del diagrama de estados al panorama del UML 




A1 finalizar la hora anterior, dije que aqui tratarfa una nueva cate- 
gorfa de elementos con la cual no habia trabajado, el elemento de 



comportamiento, este muestra la forma en que las partes de un modelo UML 



cambian con el tiempo. Vera un miembro en particular de esta categorfa, el 
diagrama de estados. 




Cada ano trae consigo nuevos estilos en ropas y automoviles, las estaciones cambian 
el color de las hojas de los arboles y cada ano que pasa deja entrever el crecimiento 
y madurez de los ninos. A1 pasar el tiempo y conforme suceden las cosas, hay cambios 
que afectan a los objetos que nos rodean. 

Esto tambien se aplica en cualquier sistema. Conforme el sistema interactua con los 
usuarios y (posiblemente) con otros sistemas, los objetos que lo conforman pasaran por 
cambios necesarios para ajustar las interacciones. Si va a modelar sistemas, necesitara 
contar con un mecanismo para los cambios en el modelo. 



Que es un diagrama de estados 

Una manera para caracterizar un cambio en un sistema es decir que los objetos que lo 
componen modificaron su estado como respuesta a los sucesos y al tiempo. He aqui 
algunos ejemplos rapidos: 

Cuando acciona el interruptor, la fuente de luz cambia su estado de apagada a 
encendida. 

Cuando presiona un boton de un control remoto, una television cambia su estado para 
mostrarle un canal u otro. 

Luego de un lapso adecuado, una lavadora cambia su estado de “lavar” a “enjuagar”. 
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El diagrama de estados UML captura este tipo de cambios. Presenta los estados 
en los que puede encontrarse un objeto junto con las transiciones entre los 
estados, y muestra los puntos inicial y final de una secuencia de cambios de estado. 
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Un diagrama de estados tambien se conoce como un motor 
de estado. 



Tenga en cuenta que un diagrama de estados es intnnsecamente distinto, de manera muy 
significativa, de uno de clase, de objeto o de un caso de uso. Los diagramas que ya ha 
visto modelan el comportamiento de un sistema, o al menos un grupo de clases, objetos 
o casos de uso. Un diagrama de estados muestra las condiciones de un solo objeto. 

Simbologia 

La figura 8.1 le muestra el rectangulo de vertices redondeados que representa a un estado, 
junto con una llnea continua y una punta de flecha, mismas que representan a una tran- 
sition. La punta de la flecha apunta hacia el estado donde se hara la transition. La figura 
tambien muestra un cfrculo relleno que simboliza un punto inicial y la diana que repre- 
senta a un punto final. 





Figura 8.1 

Los si'mbolos UML en 
un diagrama de estados. 

El icono para el estado 
es un rectangulo de 
vertices redondeados , 
y el sfmbolo de una 
transicion es una linea 
continua y una punta 
de flecha. Un circulo 
relleno se interpreta 
coma el punto initial de 
una secuencia de esta- 
dos, y una diana repre- 
senta al punto final 

Adicion de detalles al icono de estado 

El UML le da la option de agregar detalles a la simbologfa. Asi como es posible dividir un 
sfmbolo de clase en tres areas (nombre, atributos y operaciones), puede dividir el icono 
de estado de igual forma. El area superior contendra el nombre del estado (que tiene que 
establecer ya sea que haya la subdivision o no), el area central contendra las variables 
de estado, y el area inferior las actividades. La figura 8.2 le muestra estos detalles. 

Figura 8.2 

Puede subdividir el 
simbolo del estado 
en areas que muestren 
el nombre, variables y 
actividades del estado. 

Las variables de estado como cronometros o contadores son, en ocasiones, de ayuda. 

Las actividades constan de sucesos y acciones: tres de las mas utilizadas son entrada 
(que sucede cuando el sistema entra al estado), salida (que sucede cuando el sistema 
sale del estado), y hacer (que sucede cuando el sistema esta en el estado). Puede agregar 
otros conforme sea necesario. 

Un maquina de fax sirve como ejemplo de un objeto que puede pasar por diversas varia- 
bles y actividades de estado. Cuando se envfa un fax — esto es, cuando se encuentra en 
estado de envfo de fax — la maquina de fax anota la fecha y hora en que initio el envfo 
(los valores de las variables de estado “fecha” y “hora”), y tambien anota su numero tele- 
fonico asf como el nombre del propietario (los valores de las variables de estado “telefono” 
y “propietario”). Al encontrarse en este estado, la maquina se encarga de agregar un 
registro de fecha y hora al fax, numero telefonico y nombre del propietario. En otras 
actividades de este estado, la maquina jalara las hojas, paginara el fax y finalizara la 
transmision. 








Mientras se encuentre en el estado de inactividad, la maquina de fax mostrara la fecha y 
la hora en una pantalla. La figura 8.3 le muestra el diagrama de estados. 



Figura 8.3 

La maquina de fax 
es un huen ejemplo de 
un estado con variables 
y actividades. 




Sucesos y acciones 

Tambien puede agregar ciertos detalles a las lineas de transicion. Puede indicar 
un suceso que provoque una transicion ( desencadenar un suceso ), y la actividad 
de computo {la accion) que se ejecute y haga que suceda la modification del estado. 

A los sucesos y acciones los escribira cerca de la lfnea de transicion mediante una dia- 
gonal para separar un suceso desencadenado de una accion. En ocasiones un evento 
causara una transicion sin una accion asociada, y algunas veces una transicion sucedera 
dado que un estado finalizara una actividad (en lugar de hacerlo por un suceso). A este 
tipo de transicion se le conoce como transicion no desencadenada . La GUI (interfaz 
grafica de usuario) con que interactue le dara ejemplos de detalles de la transicion. Por el 
momento, asumamos que la GUI puede establecerse en uno de tres estados: 
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Initialization 

Operacion 

Apagar 






Cuando encienda su equipo, se ejecutara un proceso de arranque. A1 encender la PC se 
desencadena un suceso que provoca que la GUI aparezca luego de una transition desde el 
estado de Initialization, y el arranque es una action que se realiza durante tal transition. 

Como resultado de las actividades en el estado de initialization, la GUI entra al modo de 
Operation. Cuando desea apagar su PC, desencadena un suceso que provoca la transition 
hacia el estado de Apagado, y con ello la PC se apaga. La figura 8.4 muestra el diagrama 
de estados que captura los estados y transiciones en la GUI. 



Figura 8.4 

Los estados y transi- 
ciones de una interfaz 
grdfica del usuario 
incluyen el desencade- 
namiento de eventos , 
acciones v transiciones 
no desencadenadas. 



Encender la PC 

I > 1 



Inicializacion 



ace r/Arra near] 




Condiciones de seguridad 

La anterior secuencia de estados de la GUI deja mucho que desear. Por ejemplo: si deja 
solo su equipo o si realizara alguna actividad en la que no tocara al raton o al teclado, 
podria aparecer un protector de pantallas que evitarfa el desgaste de su pantalla. Para 
decir esto en terminos de cambio de estado, si ha pasado cierto tiempo sin que haya 
interaction con el usuario, la GUI hara una transition del estado Operation a un estado 
que no aparece en la figura 8.4: el estado de Protector de pantallas. 

El intervalo se especifica en el panel de control de su sistema operativo (Windows en 
este caso). Por lo general es de 15 minutos. Cualquier opresion de una tecla o 
movimiento del raton provocara una transition del estado Protector de pantallas al 
estado Operation. 
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El intervalo de 15 minutos es una condicion de seguridad : cuando se llega a 
ella, se realiza la transition. La figura 8.5 muestra el diagrama de estados de la 
GUI con el estado Protector de pantalla y la condicion de seguridad anadida. Vea que 
la condicion de seguridad se establece como expresion booleana. 



Figura 8.5 

El diagrama 
de estados para 
la GUI , con el estado 
Protector de pantalla 
y la condicion 
de seguridad . 










Subestados 

Nuestro modelo de la GUI aun esta algo vacfo. El estado Operacion, en particular, es 
mucho mas sustancioso de lo que he indicado en las figuras 8.4 y 8.5. 



Cuando la GUI esta en el estado Operacion, hay muchas cosas que ocurren tras bambali- 
nas, aunque no sean particularmente evidentes en la pantalla. La GUI aguarda de forma 
constante a que usted haga algo (oprimir una tecla, mover el raton u oprimir uno de sus 
botones). Luego, debera registrar tales acciones y modificar lo que se despliega para 
reflejarlas en la pantalla (como mover el cursor cuando usted mueva el raton, o mostrar 
una “a” cuando usted oprima la tecla “a”)- 
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Con ello la GUI atravesara por varios cambios mientras se encuentre en el 
estado Operacion. Tales cambios seran cambios de estado. Dado que estos 
estados se encuentran dentro de otros, se conoceran como subestados. Hay dos tipos 
de subestados: secuencial y concurrente. 



Subestados secuenciales 

Como su nombre lo indica, los subestados secuenciales suceden uno detras de otro. Si 
retomamos los subestados mencionados con anterioridad dentro del estado Operacion 
de la GUI, tendra la siguiente secuencia: 

A la espera de accion del usuario 
Registro de una accion del usuario 
Representacion de la accion del usuario 

La accion del usuario desencadena la transicion a partir de A la espera de accion del 
usuario hacia Registro de una accion del usuario. Las actividades dentro del Registro 
trascienden de la GUI hacia la Representacion de la accion del usuario. Despues del 
tercer estado, la GUI vuelve a iniciar A la espera de accion del usuario. La figura 8.6 
le muestra como representar los subestados secuenciales dentro del estado Operacion. 

Figura 8.6 

Subestados secuencia- 
les dentro del estado 
Operacion de la GUI. 











Operacion 








r 




f N 




/ — > 






A la espera 




Registro de 




Representacion 






de accion 


Accion ^ 


una accion 




de la accion 








del usuario 




del usuario 




del usuario 


“I 






^ J 




^ J 


V J 
















1 


V 


J 



Subestados concurrentes 

Dentro del estado Operacion, la GUI no solo aguarda a que usted haga algo. Tambien 
verifica el cronometro del sistema y (posiblemente) actualiza el despliegue de una 
aplicacion luego de un intervalo especi'fico. Por ejemplo, una aplicacion podrfa incluir 
un reloj en pantalla que tuviera que actualizar la GUI. 





Todo esto sucede al mismo tiempo que la secuencia que ya indique. Aunque cada secuen- 
cia es, claro, un conjunto de subestados secuenciales, las dos secuencias son concurrentes 
entre si. Puede representar la concurrencia con una linea discontinua entre los estados 
concurrentes, como en la figura 8.7. 



Figura 8.7 

Los subestados con- 
currentes sucede n 
al mismo tiempo. 

Una Unea discontinua 
los separa. 
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La separation del estado Operacion en dos componentes podrfa recordarle algo. 
^Recuerda cuando trate el tema de las adiciones y composiciones? Cuando 
cada componente sea parte de un “todo”, tratara con una composition. Las partes concu- 
rrentes del estado Operacion tienen el mismo tipo de relation con el. Por ello, el estado 
Operacion es un estado compuesto . Un estado que consta solo de subestados secuenciales, 
tambien es un estado compuesto. 



Estados historicos 

Cuando se activa su protector de pantallas y mueve su raton para regresar al estado 
Operacion ^que ocurre? ^Acaso su pantalla retoma el estado inicial, como si apenas se 
hubiera encendido? ^O lucira tal como la dejo antes de que se activara el protector de 
pantallas? 

Es obvio, si el protector de pantallas provocara que la pantalla regresara a su estado ini- 
cial de operacion, la idea del protector de pantallas serfa contraproducente. Los usuarios 
podrfan perder su trabajo y tendrfan que reiniciar una sesion nuevamente. 

El diagrama de estados historicos captura esta idea. El UML proporciona un simbolo que 
muestra que un estado compuesto recuerda su subestado activo cuando el objeto trasciende 
fuera del estado compuesto. El simbolo es la letra “H” encerrada en un circulo que se 
conecta por una linea continua al subestado por recordar, con una punta de flecha que 
apunta a tal subestado. La figura 8.8 muestra este simbolo en el estado Operacion. 





Figura 8.8 

El estado historico, 
simbolizado con la “H" 
dentro del circulo, le 
muestra que un estado 
compuesto recuerda 
su subestado activo 
cuando el objeto 
trasciende fuera de 
tal estado compuesto. 



[Lapso transcurrido] 
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En el diagrama de estados no he tratado con las ventanas que estan abiertas por 
otras ventanas (es decir, con subestados anidados en otros). Cuando un estado 
historico recuerda los subestados en todos los niveles de anidacion (como el estado 
Operation de Windows lo hace), el estado historico es prof undo. Si solo recuerda el 
subestado principal, el estado historico sera superficial. Un estado historico profundo 
se representa agregando un asterisco (*) a la “H” en el circulo (H*). 




El estado historico y el estado inicial (representados por 

el circulo relleno) son conocidos como pseudoestados. 

No tienen variables de estados ni actividades, por lo que no son estados 
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"completos" 



Mensajes y senates 

En el ejemplo, el suceso desencadenado que provoco la transicion de Protector de pantalla 
a Operacidn es la opresion de una tecla, un movimiento del raton o una opresion de uno 
de sus botones. Cualquiera de estos sucesos es, en efecto, un mensaje del usuario a la 
GUI. Esto es un concepto importante dado que los objetos se comunican mediante el 
envio de mensajes entre si. En este caso, el suceso desencadenado es un mensaje de un 
objeto (el usuario) a otro (la GUI). 










Un mensaje que desencadena una transition en el diagrama de estados del 
objeto receptor se conoce como serial . En el mundo de la orientation a objetos, 
el envio de una senal es lo mismo que crear un objeto Senal y transmitirlo al objeto 
receptor. El objeto Senal cuenta con propiedades que se representan como atributos. 

Dado que una senal es un objeto, es posible crear jerarquias de herencia de senates. 

Por que son importantes 
los diagramas de estados 

El diagrama de estados del UML proporciona una gran variedad de simbolos y abarca 
varias ideas (todas para modelar los cambios por los que pasa un objeto). Este tipo de 
diagrama tiene el potential de convertirse en algo complejo con pasmosa rapidez. ^.En 
verdad es necesario? 

De hecho, asi es. Es necesario contar con diagramas de estados dado que permiten a los 
analistas, disenadores y desarroll adores comprender el comportamiento de los objetos de 
un sistema. Un diagrama de clases y el diagrama de objetos correspondiente solo muestra 
los aspectos estaticos de un sistema. Muestran las jerarquias y asociaciones, y le indican 
que son las operaciones. Pero no le muestran los detalles dinamicos de las operaciones. 

Los desarroll adores, en particular, deben saber la forma en que los objetos se supone que 
se comportaran, ya que son ellos quienes tendran que establecer tales comportamientos 
en el software. No es suficiente con implementar un objeto: los desarrolladores deben 
hacer que tal objeto haga algo. Los diagramas de estados se aseguran que no tendran que 
adivinar lo que se supone que haran los objetos. Con una tiara representation del com- 
portamiento del objeto, aumenta la probabilidad de que el equipo de desarrollo produzca 
un sistema que cumpla con los requerimientos. 

Adiciones al panorama 

Ahora puede agregar los “Elementos de comportamiento” al panorama del UML. La 
figura 8.9 le muestra la imagen con el diagrama de estados incluido. 
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Elementos de comportamiento 



Figura 8.9 

El panorama del 
UML ahora incluye 
un elemento de com- 
portamiento: el dia- 
grama de estados. 

La organizacion del 
UML, en terminos 
de los elementos 
que ha utilizado 
hasta ahora. 



Elementos estructurales 




Relaciones 

Asociaci6n 

Generalizaci6n 

Dependencia 

£> Realizacidn 



Agrupacidn 



Paquete 



Extension 

«Estereotipo» 
{Restriccion} 
{valor etiquetado} 



Anotacidn 




Resumen 

Los objetos en los sistemas modifican sus estados como respuestas a sucesos y al tiempo. 
El diagrama de estados de UML captura estos cambios de estado. Un diagrama de estados 
se enfoca en los cambios de estado en un solo objeto. Un rectangulo de vertices redon- 
deados representa a un estado, y una lfnea continua con una punta de flecha representa 
una transicion de un estado a otro. 

El sfmbolo del estado contiene el nombre del mismo y puede tener variables y actividades 
del estado. Una transicion puede suceder como respuesta a un suceso desencadenado, 
e implicar una respuesta o accion. Una transicion tambien puede ocurrir por la actividad 
en un estado: una transicion que ocurre de esta forma se conoce como transicion no desen- 
cadenada. Finalmente, una transicion puede ocurrir cuando se cumple una condicion 
particular, o condicion de seguridad. 

En ocasiones, un estado consta de subestados. Los subestados pueden ser secuenciales 
(ocurrir uno despues del otro) o concurrentes (ocurrir al mismo tiempo). Un estado que 
consta de subestados se conoce como estado compuesto. Un estado historico indica que un 
estado compuesto recordara su subestado cuando el objeto trascienda de este estado com- 
puesto. Un estado historico puede ser superficial o profundo. Tales terminos son propios 
de los subestados anidados. Un estado historico superficial recuerda s61o el subestado 
principal. Un estado historico profundo recuerda todos los niveles de los subestados. 






Cuando un objeto envia un mensaje que desencadena una transition en el diagrama de 
estados de otro objeto, tal mensaje es una serial Una serial es, por si misma, un objeto, 
y podra crear una jerarquia de herencia de las senates. 

Es necesario contar con los diagramas de estados porque facilitan la comprension de 
los objetos de un sistema a los analistas, disenadores y desarrolladores. Los desarrolla- 
dores, en particular, deben saber como se supone que se comportaran los objetos, dado 
que seran quienes tengan que establecer estos comportamientos en el software. No es 
suficiente implementar un objeto: los desarrolladores tienen que hacer que tal objeto 
haga algo. 

Preguntas y respuestas 

P ^Cual es la mejor manera de empezar a crear un diagrama de estados? 

R Es muy parecido a crear un diagrama de clases o un modelo de caso de uso. En el 
diagrama de clases, listara todas las clases y luego realizara las asociaciones entre 
ellas. En el diagrama de estados, primero listara los estados del objeto, y luego se 
enfocara en las transiciones. Conforme avance en cada transition, debera prever si 
un suceso desencadenado lo activara y si se realizara alguna action. 

P <,Cada diagrama de estados debe tener un estado final (el que se representa 
por la diana)? 

R No. Un objeto que nunca queda inactivo jamas tendra un estado final. 

P ^Alguna sugerencia para disenar un diagrama de estados? 

R Intente arreglar los estados y transiciones para minimizar el cruzamiento 

de lineas. Uno de los objetivos de este diagrama (y de cualquier otro) se centra 
en la claridad. Si las personas no pueden comprender los modelos que cree, nadie 
los usara y sus esfuerzos (no importa que tan minuciosos hayan sido) habran sido 
infruetuosos. 



Taller 

El cuestionario y los ejercicios le haran trascender al estado “Aprendizaje de diagramas 
de estados”. Como siempre, encontrara las respuestas en el Apendice A, “Respuestas a 
los cuestionarios”. 

Cuestionarios 

1. ^De que forma difiere un diagrama de estados de uno de clases, de objetos o de 
caso de uso? 

2. Defina los siguientes terminos: transicion , suceso y accidn. 

3. ^Que es una transicion no desencadenadal 

4. ^Cual es la diferencia entre los subestados secuenciales y los concurrentes? 




Ejercicios 

1. Suponga que disenara un tostador. Cree el diagrama de estados que controle los 
estados del pan en el tostador. Incluya los sucesos desencadenados, acciones y 
condiciones de seguridad necesarios. 

2. Cada vez que un objeto envfe una senal, se creara un objeto Senal y sera transmi- 
tido. En Windows, hay varias senales posibles a partir de la GUI. Suponga que la 
senal (el tipo de senal que envfe a Windows) sea una clase. U.Que tipo de clase es?) 
Cree un diagrama de clases de las posibles senales y muestre toda la herencia 
inherente. 

3. La figura 8.7 le muestra los subestados concurrentes dentro del estado Operation de 
la GUI. Dibuje un diagrama del estado Protector de pantalla que incluya los subesta- 
dos concurrentes. 
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Diagramas de secuencias 

Los diagramas de estados se enfocan a los diferentes estados de un objeto. 
Esto es solo una pequena parte del cuadro. El diagrama de secuencias del 
UML establece el siguiente paso y le muestra la forma en que los objetos 
se comunican entre si al transcurrir el tiempo. 

En esta hora se trataran los siguientes temas: 

• Que es un diagrama de secuencias 

• La GUI 

• Diagramas de instancias y diagramas genericos 

• Uso de “si” y “mientras” 

• Creadon de un objeto en la secuencia 

• Representacion de la recursividad 

• Diagramas de secuencias en el panorama del UML 

Los diagramas de estados que vio en la hora anterior se centran en un objeto 
y muestran los cambios por los que pasa dicho objeto. 



El UML le permite expandir su campo de vision y le muestra la forma en que un objeto 
interacciona con otros. En este campo de vision expandido, incluira una importante 
dimension: el tiempo. La idea primordial es que las interacciones entre los objetos se 
realizan en una secuencia establecida y que la secuencia se toma su tiempo en lr del 
principio al fin. A1 momento de crear un sistema tendra que especificar la secuencia, y 
para ello, utilizara al diagrama correspondiente. 



Que es un diagrama de secuencias 



Termino Nuevo 



El diagrama de secuencias consta de objetos que se representan del modo usual: 
rectangulos con nombre (subrayado), mensajes representados por h'neas conti- 
nuas con una punta de flecha y el tiempo representado como una progresion vertical. 

Objetos 



Termino Nuevo 



Los objetos se colocan cerca de la parte superior del diagrama de izquierda a 
____ derecha y se acomodan de manera que simplifiquen al diagrama. La extension 
que esta debajo (y en forma descendente) de cada objeto sera una lmea discontinua co- 
nocida como la linea de vida de un objeto. Junto con la lmea de vida de un objeto se 
encuentra un pequeno rectangulo conocido como activacion, el cual representa la eje- 
cucion de una operacion que realiza el objeto. La longitud del rectangulo se mterpreta 
como la duracion de la activacion. La figura 9. 1 muestra un objeto, su lmea de v,da y su 
activacion. 



Figura 9.1 

Representation de un 
objeto en un diagrama 
de secuencias. 



:Nombre 



D 



Mensaje 

Un mensaje que va de un objeto a otro pasa de la lmea de vida de un objeto a la de otro. 
Un objeto puede enviarse un mensaje a sf mismo (es decir, desde su lmea de vida hacia 
su propia lmea de vida). 

Un mensaje puede ser simple, sincronico, o asincronico. Un mensaje simple es la trans- 
ference del control de un objeto a otro. Si un objeto envfa un mensaje sincronico, espe- 
rara la respuesta a tal mensaje antes de continuar con su trabajo. Si un objeto envfa un 
mensaje asincronico, no esperara una respuesta antes de continuar. En el diagrama de 
secuencias, los sfmbolos del mensaje varian, por ejemplo, la punta de la flecha de un 
mensaje simple esta formada por dos lfneas, la punta de la flecha de un mensaje sin- 
cronico esta rellena y la de un asincronico tiene una sola lmea, como se aprecia en la 
figura 9.2. 






Figura 9.2 

Simbolos para los 
mensajes en un dia- 
grama de secuencias. 



> Simple 
— ► Sincronico 
Asincronico 



Tiempo 

El diagrama representa al tiempo en direction vertical. El tiempo se inicia en la parte 
superior y avanza hacia la parte inferior. Un mensaje que este mas cerca de la parte supe- 
rior ocurrira antes que uno que este cerca de la parte inferior. 

Con ello, el diagrama de secuencias tiene dos dimensiones. La dimension horizontal es la 
disposition de los objetos, y la dimension vertical muestra el paso del tiempo. La figura 
9.3 muestra al conjunto basico de simbolos del diagrama de secuencias, con los simbolos 
en funcionamiento conjunto. La figura muestra a un actor que inicia la secuencia, 
aunque, en sentido estricto, la figura adjunta no es parte del conjunto de simbolos del 
diagrama de secuencias. 



Figura 9.3 

En un diagrama de 
secuencias los objetos 
se colocan de izquierda 
a derecha en la parte 
superior. Cada h'nea 
de vida de un objeto es 
una linea discontinua 
que se desplaza hacia 
abajo del objeto. Una 
linea continua con una 
punta de flecha conecta 
a una linea de vida con 
otra, y representa un 
mensaje de un objeto a 
otro. El tiempo se inicia 
en la parte superior y 
continua hacia abajo. 
Aunque un actor es el 
que normalmente inicia 
la secuencia, su simbolo 
no es parte del conjunto 
de simbolos del dia- 
grama de secuencias. 




Para ver en action a esta importante herramienta del UML, apliquemosla en los ejemplos 
que hemos visto en las horas anteriores. Cada aplicacion le mostrara algunos conceptos 
importantes que se relacionan con los diagramas de secuencias. 





La GUI 

En la hora anterior desarrollo los diagramas de estados que muestran los cambios por los 
que pasa una GUI. Ahora dibujara un diagrama de secuencias que represente las interac- 
tividades de la GUI con otros objetos. 

La secuencia 

Suponga que el usuario de una GUI presiona una tecla alfanumerica; si asumimos que 
utiliza una aplicacion como un procesador de textos, el caracter correspondiente debera 
aparecer de inmediato en la pantalla. <,Que ocurre tras bambalinas para que esto suceda? 

1 . La GUI notifica al sistema operativo que se oprimio una tecla. 

2. El sistema operativo le notifica a la CPU. 

3. El sistema operativo actualiza la GUI. 

4. La CPU notifica a la tarjeta de video. 

5. La tarjeta de video envla un mensaje al monitor. 

6. El monitor presenta el caracter alfanumerico en la pantalla, con lo que se hara 
evidente al usuario. 

Todo esto ocurre con tanta rapidez que olvidamos que todo ello se realiza. (jSi acaso 
pensabamos que ocurrla!) 

El diagrama de secuencias 

La figura 9.4 representa el diagrama de secuencias de la GUI. Como ve, los mensajes 
son asincronicos: ninguno de los componentes aguarda nada antes de continuar. Al traba- 
jar con algunas aplicaciones de Windows, tal vez haya sentido algunos de los efectos de 
la comunicacion asincronica, particularmente en una maquina lenta. Cuando teclea en 
un procesador de textos, en ocasiones no ve aparecer en la pantalla el caracter correspon- 
diente a la tecla que haya oprimido sino hasta despues de haber oprimido algunas mas. 




Figura 9.4 

Un diagrama de se- 
cuencias que muestra 
la forma en que la 
GUI interacciona 
con otros objetos. 




En ocasiones, es muy instructive mostrar los estados de uno o varios de los objetos en 
el diagrama de secuencias. Dado que ya ha analizado los estados de la GUI (en la hora 
anterior), esto es facil de hacer. La figura 9.5 le muestra un hibrido: el diagrama de 
secuencias de la GUI con los estados de la GUI. Observe que la secuencia se origina 
y finaliza en el estado Operativo de la GUI, como podna esperarlo. 



Figura 9.5 

Un diagrama de 
secuencias puede 
mostrar los estados 
de un objeto. 








En un diagrama de secuencias, otra forma de mostrar ei cambio de estado 
de un objeto es incluir al objeto mas de una vez en el diagrama. 



El caso de uso 

^Que es exactamente lo que representa un diagrama de secuencias? En este ejemplo, 
muestra las interacciones de objetos que se realizan durante un escenario sencillo. la 
opresion de una tecla. Este escenario podrfa ser parte de un caso de uso llamado “Ejecutar 
la opresion de una tecla” (vea la figura 9.6). Al representar graficamente las interacciones 
del sistema en el caso de uso, el diagrama de secuencias habra, en efecto, 'delineado ’ el 
caso de uso dentro del sistema. 



Figura 9.6 

El caso de uso repre- 
sentado graficamente 
por el diagrama 
de secuencias de 
la figura 9.4. 




En el siguiente ejemplo, examinare detalladamente la relacion entre los casos de uso y 
los diagramas de secuencias. 

Instancias y genericos 

El ejemplo anterior comenzo con un diagrama de estados. Este otro ejemplo empieza 
con un caso de uso. “Comprar gaseosa” fue uno de los casos de uso del ejemplo de la 
maquina de gaseosas en las horas 6, “Introduction a los casos de uso”, y 7, “Diagramas 
de casos de uso”. 

Un diagrama de secuencias de instancias 

En el mejor escenario del caso de uso “Comprar gaseosa , recuerde que el actor es un 
cliente que desea adquirir una lata de gaseosa. El cliente inicia el escenario mediante la 
insertion de dinero en la maquina. Luego hace una selection. Dado que hablamos del 
mejor escenario, la maquina tiene al menos una lata de la gaseosa elegida y por lo tanto 
presenta una lata frfa al cliente. 

Asumamos que en la maquina de gaseosas hay tres objetos que realizan la tarea que nos 
ocupa: la fachada (la interfaz que la maquina de gaseosas presenta al usuano), el regis- 
trador de dinero (que lo recolecta), y el dispensador (que entrega la gaseosa). Tambien 
daremos por hecho que el registrador de dinero controlara al dispensador. La secuencia 
sera como sigue: 





1. El cliente inserta el dinero en la alcancfa que se encuentra en la fachada de la 
maquina. 

2. El cliente hace su election. 

3. El dinero viaja hacia el registrador. 

4. El registrador verifica si la gaseosa elegida esta en el dispensador. 

5. Dado que es el mejor escenario, asumimos que si hay gaseosas, y el registrador 
actualiza su reserva de efectivo. 

6. E! registrador hace que el dispensador entregue la gaseosa en la fachada de la 
maquina. 

Dado que el diagrama de secuencias solo se centra en un escenario (una instan- 
ce) en el caso de uso “Comprar gaseosa”, se conoce como diagrama 
de secuencias de instancias. La figura 9.7 le muestra este diagrama. Vea que el diagrama 
muestra mensajes sencillos. Cada mensaje mueve el flujo de control de un objeto a otro. 



Termino Nuevo 



Figura 9.7 

Este diagrama de se- 
cuencias modela tan 
solo el mejor esce- 
nario del caso de uso 
“Comprar gaseosa 
Por lo tanto, es un 
diagrama de secuen- 
cias de instancias . 




Un diagrama de secuencias generico 

Como recordara, el caso de uso “Comprar gaseosa” tenia dos escenarios altemos. Uno 
de ellos se referfa al hecho de que la maquina no tuviera la gaseosa seleccionada y el 
otro cuando el cliente no contaba con el dinero exacto. Si tomara en cuenta todos los 
escenarios de un caso de uso al momento de crear un diagrama de secuencias, se tratana 
de un diagrama de secuencias generico. 

En este caso podra generar el diagrama de secuencias generico a partir del diagrama 
de secuencias de instancias. Para ello tendra que justificar el control del flujo. Esto es, 
tendra que representar las condiciones y consecuencias de “Monto incorrecto” y “Sin 
gaseosa”. 

Para el escenario relacionado con “Monto incorrecto”. 

1. El registrador verifica si la alimentation del usuario concuerda con el precio de la 
gaseosa. 

2. Si el monto es mayor que el precio, el registrador calcula la diferencia y verifica si 
cuenta con cambio. 





3. Si se puede devolver la diferencia, el registrador devuelve el cambio al cliente y 
todo transcurre como antes. 

4. Si la diferencia no se encuentra en la reserva del cambio, el registrador regresara 
el monto alimentado y mostrara un mensaje que indique al cliente que inserte el 

monto exacto. 

5. Si la cantidad insertada es menor al precio, el registrador no hace nada y la 
maquina esperara mas dinero. 




Si disefia una maquina de gaseosas para un cliente, tal vez tenga que tomar 
una decision de diseno respecto al paso 5. Podra hacer que la maquina aguar- 
de cierto tiempo, calcule la diferencia entre el precio y el monto insertado, y 
que muestre un mensaje que solicite al cliente que inserte la diferencia. 

Como parte de la decision, tendra que responder a estas preguntas: <.Que 
tanto le important esta facultad al cliente? iCuanto costaria implementar la 
tecnologla que lograra lo anterior? 

Este es un buen ejemplo de la forma en que un diagrama de secuencias 
puede influir en el proceso de analisis. 



Para representar cada condicion en la secuencia, tal condicion la colocara en un ‘si 
(un si condicional) entre corchetes. Arriba de las flechas de mensaje apropiadas, agregue 
[alimentacion > precio], [alimentacion - precio no presente] y [alimentacion - precio 

presente]. 

Cada condicion causara una bifurcacion del control en el mensaje, que separara al men- 
saje en rutas distintas. Como cada ruta ira al mismo objeto, la bifurcacion causara una 
“ramificacion” del control en la l.'nea de vida del objeto receptor, y separara las l.neas de 
vida en rutas distintas. En algun lugar de la secuencia, las ramas del mensaje confluiran, 
como las bifurcaciones en las lfneas de vida. 

La figura 9.8 muestra un diagrama luego de agregar el escenario de “Monto incorrecto”. 





Figura 9.8 

El diagrama de 
secuencias luego 
de agregar el 
e scenario de "Mon to 
incorrecto” al caso 
de uso “ Comprar 
gaseosa ”. 
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Ahora agregaremos el escenario “Sin gaseosa”. 

1. Una vez que el cliente elige una marca agotada, la maquina mostrara un mensaje 
de “Agotado”. 

2. La maquina mostrara un mensaje que solicitara al cliente que haga otra election. 

3. El cliente tendra la opcidn de oprimir un boton para que se le regrese su dinero. 

4. Si el cliente elige una marca en existencia, todo procedera como en el mejor esce- 
nario si el monto insertado es correcto. Si no lo es, la maquina seguira por el 
escenario del “Monto incorrecto”. 

5. Si el cliente elige otra marca agotada, el proceso se repetira hasta que el cliente 
elija una marca en existencia o presione un boton que le regrese su dinero. 

La figura 9.9 le muestra el diagrama de secuencias generico de la maquina de gaseosas 
con los escenarios “Monto incorrecto” y “Sin marca”. 







Figura 9.9 

El diagrama de 
secuencias generico 
de la maquina de 
gaseosas luego 
de agregarle 
el e scenario 
“Sin marca ” 
a la figura 9.8 . 



f. 




Si empieza a pensar que un diagrama de secuencias esta imph'cito en cada caso de uso, 
ya tiene la idea. 

Creation de un objeto en la secuencia 

En los ejemplos que hemos visto ha analizado distintos tipos de mensajes, diagramas 
de secuencias generico y de instancias, asi como estructuras de control. Otro concepto 
importante relacionado con los diagramas de secuencias, particularmente cuando disene 
software, es la creacion de objetos. 

Con frecuencia se da el caso de que un programa orientado a objetos debe crear un 
objeto. Recuerde que en terminos del software, una clase es una plantilla para crear 
un objeto (como un molde de galletas para crear una galleta). i.Como representarfa la 
creacion de un objeto cuando represente una secuencia de interacciones entre objetos . 

El caso de uso “Crear una propuesta” del ejemplo de la LAN en una firma de consultona 
nos muestra una instancia de la creacion de objetos. En este ejemplo conceb.ra la LAN 
en el entendido de que todo se realiza mediante la red. Si damos por hecho que el consul- 
tor ya ha iniciado una sesion en la LAN, la secuencia que modelara quedara como s.gue: 

1 El consultor querra volver a utilizar partes de una propuesta existente y busca en 
un area centralizada de la red una propuesta adecuada. 

2. Si el consultor encuentra una propuesta adecuada, abrira el archivo y, en el proceso, 
abrira el software integrado para la oficina relacionada. El consultor guardara el 
archivo con un nuevo nombre, con lo que creara un archivo nuevo para la nueva 
propuesta. 



3. Si el consultor no encuentra una propuesta, abrira la aplicacion de oficina y creara 
un archivo para la propuesta. 

4. A1 trabajar en la propuesta, el consultor utilizara las aplicaciones del software inte- 
grado para oficina. 

5. Cuando el consultor finalice la propuesta, la guardara en el area de almacenamiento 
centralizada. 

Ademas de la creacion de objetos (en este caso, de archivos), esta secuencia trae consigo 
el uso de “si” asf como de un ciclo “mientras”. 

Primero veamos lo relacionado con la creacion de objetos. Cuando una secuen- 
cia da por resultado la creacion de un objeto, tal objeto se representara de la 
forma usual: como un rectangulo con nombre. La diferencia es que no lo colocara en 
la parte superior del diagrama de secuencias, sino que lo colocara junto con la dimension 
vertical, de modo que su ubicacion corresponda al momento en que se cree. El mensaje 
que creara al objeto se nombrara “Crear()”. Los parentesis implican una operacion: en 
un lenguaje orientado a objetos, una operacion constructor genera un objeto. 



Termino Nuevo 




En lugar de usar "CrearO" o "CreateO" para etiquetar la flecha de un mensaje 
de creacion de un objeto, podria valerse de un estereotipo llamado «Crear». 



En el caso de “mientras”, a este control de flujo lo representara colocando la condition 
mientras (“mientras se trabaja en una propuesta”) entre corchetes, con un asterisco (*) 
antes del primer corchete. 

La figura 9. 10 le muestra el diagrama de secuencias del caso de uso “Crear una propuesta”. 




Este ejemplo represents una abstraccion en la que he omitido detalles que 
no nos competen en lo particular. Esto lo he hecho de dos formas. Primero, 
obvie los detalles de la LAN, como lo mencione. Tambien vea que la GUI es 
un objeto en el diagrama de secuencias, y que no he induido toda la com- 
plejidad del caso de uso "Teclazo" del ejemplo anterior. Los detalles de la 
interaccion de la GUI con el sistema operativo, la CPU y el monitor no son 
importantes en este caso. 






Figura 9.10 

El diagrama de 
secuencias del caso 
de uso “Crear una 
propuesta” . 




Como representar la recursividad 



En ocasiones un objeto cuenta con una operation que se invoca a si misma. 

A esto se le conoce como recursividad , y es una caracterfstica fundamental de 
varios lenguajes de programacion. 



Termino Nuevo 



He aqui un ejemplo. Suponga que uno de los objetos en su sistema sea una calculadora, y 
que una de sus operaciones sea el calculo de intereses. Para calcular el interns compuesto 
para un periodo que incluya a varios periodos, la operacion del calculo de intereses del 
objeto tendra que invocarse a si misma varias veces. 

Para representar esto en el UML, dibujara una flecha de mensaje fuera de la activacion 
que signifique la operacion, y un pequeiio rectangulo sobrepuesto en la activacion. Dibuje 
una flecha de modo que apunte al pequeno rectangulo, y una que regresa al objeto que 
inicio la recursividad. La figura 9.1 1 muestra lo anterior. 



Figura 9.11 

Como representar 
la recursividad 
en un diagrama 
de secuencias. 
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Adiciones al panorama 

Ahora podra agregar otro diagrama a su panorama del UML. Dado que se refiere al com- 
portamiento de los objetos, el diagrama de secuencias ina bajo la categorfa “Elementos 
de comportamiento , \ La figura 9.12 actualiza su creciente panorama. 



Figura 9.12 

El panorama del 
UML con la adicidn 
del diagrama de 
secuencias. 
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Resumen 

El diagrama de secuencias UML agrega la dimension del tiempo a las interactividades 
de los objetos. En el diagrama, los objetos se colocan en la parte superior y el tiempo 
avanza de arriba hacia abajo. La lmea de vida de un objeto desciende de cada uno de 
ellos. Un pequeno rectangulo de la lmea de vida de un objeto representa una activacion 
(la ejecucion de una de las operaciones del objeto). Puede incorporar los estados de un 
objeto colocandolos junto a su lmea de vida. 

Los mensajes (simples, sincronicos y asincronicos) son flechas que conectan a una lmea 
de vida con otra. La ubicacion del mensaje en la dimension vertical representara el mo- 
menta en que sucede dentro de la secuencia. Los mensajes que ocurren primero estan 
mas cerca de la parte superior del diagrama, y los que ocurren despues cerca de la parte 
inferior. 








Un diagrama de secuencias puede mostrar ya sea una instancia (un escenario) de un caso 
de uso, o puede ser generico e incorporar todos los escenarios de un caso de uso. Los 
diagramas de secuencias genericos con frecuencia dan la oportunidad de representar 
instrucciones condicionales y ciclos “mientras”. Bordee a cada condition con corchetes, 
y haga lo mismo en un ciclo “mientras” pero anteceda al corchete izquierdo con un 
asterisco. 

Cuando una secuencia incluya la creacion de un objeto, lo representara como un rectan- 
gulo de la forma acostumbrada. Su posicion en la dimension vertical representaran el 
momento en que se creo. 

En ciertos sistemas, una operation puede invocarse a sf misma. A esto se le conoce como 
recursividad . Se representa con una flecha que sale de la activacion hacia si misma, y un 
pequeno rectangulo sobrepuesto a la activacion. 

Preguntas y respuestas 

P El diagrama de secuencias parece que podria ser util para mas que tan solo el 
analisis de sistemas. <,Puedo usarlo para mostrar la interactividad en una 
empresa? 

R Asi es. Los objetos pueden ser los actores principles, y los mensajes pueden ser 
simples transferencias de control. 

P Usted indico la forma de representar la creacion de objetos en un diagrama de 
secuencias. ;,Los objetos tambien se destruyen, y si es asi, como lo represento? 

R Los objetos, en efecto, se destruyen. Podra representar la destruction de un objeto 
con una “X” al final de la linea de vida correspondiente a tal objeto. 



Taller 

Ahora que ha vuelto hacia los objetos y ha visto sus interactividades, venga y responda 
algunas preguntas y realice algunos ejercicios para reafirmar su conocimiento de los dia- 
gramas de secuencias. Encontrara las respuestas en el Apendice A, “Respuestas a los 
cuestionarios”. 

Cuestionario 

1. Defina mensaje sincronico y mensaje asincronico. 

2. En un diagrama de secuencias generico ^como representarfa el control de flujo 
implicito en una instruccion condicional? 

3. (,Como representarfa el control de flujo implicito en una instruccion de ciclo 
“mientras”? 

4. En un diagrama de secuencias i,c6mo representarfa a un objeto recien creado? 




Ejercicios 

1. Cree un diagrama de secuencias de instancias que muestre lo que ocurre cuando 
envia con exito un fax. Esto es, modele las interactividades entre objetos en el 
mejor escenario del caso de uso “enviar fax” de una maquina de fax. Incluya los 
objetos de la maquina que envia, la que recibe, el fax y un “intercambio” central 
que encause a los faxes y a las llamadas telefonicas. 

2. Cree un diagrama de secuencias generico que incluya escenarios infructuosos 
(lfnea ocupada, error de la maquina que envia), asi como del mejor escenario 
indicado en el ejercicio 1. 




Hora 1 0 



Diagramas 
de colaboraciones 

Ahora veremos lo correspondiente a un diagrama que es similar al que 
vimos en la hora anterior. Este tambien muestra la colaboracion entre los 
objetos, pero de una forma significativamente diferente del diagrama de 
secuencias. 

En esta hora se trataran los siguientes temas: 

• Que es un diagrama de colaboraciones 

• Como aplicar un diagrama de colaboraciones 

• Uso de “si” y “mientras” 

• Anidamiento 

• Objetos activos y concurrencia 

• Sincronizacion 

• Donde encajan los diagramas de colaboraciones en el UML 



Los diagramas de colaboraciones muestran la forma en que los objetos colaboran entre 
sf, tal como sucede con un diagrama de secuencias. Muestran los objetos junto con los 
mensajes que se envi'an entre ellos. Si el diagrama de secuencias hace eso, <,por que 
el UML requerirfa otro diagrama?, /.que no son lo mismo?, <mo es una perdida de 
tiempo? 

Ambos tipos de diagrama son similares. De hecho, son semanticamente equivalentes. 

Esto significa que representan la misma informacion, y podra convertir un diagrama 
de secuencias en un diagrama de colaboraciones equivalente y viceversa. 

Como se infiere, es util contar con ambas formas. Los diagramas de secuencias destacan 
la sucesion de las interacciones. Los diagramas de colaboraciones destacan el contexto 
y organizacion general de los objetos que interactuan. He aquf otra forma de encontrar 
la diferencia: el diagrama de secuencias se organiza de acuerdo al tiempo, y el de colabo- 
racion de acuerdo al espacio. 

Que es un diagrama de colaboraciones 

Un diagrama de objetos muestra a los objetos como tales y sus relaciones entre sf. Un 
diagrama de colaboraciones es una extension de uno de objetos. Ademas de las rela- 
ciones entre objetos, el diagrama de colaboraciones muestra los mensajes que se envfan 
los objetos entre sf. Por lo general, evitara la multiplicidad dado que podrfa ser fuente 
de confusion. 

Para representar un mensaje, dibujara una flecha cerca de la lfnea de asociacion entre 
dos objetos, esta flecha apunta al objeto receptor. El tipo de mensaje se mostrara en una 
etiqueta cerca de la flecha; por lo general, el mensaje le indicara al objeto receptor que 
ejecute una de sus operaciones. El mensaje finalizara con un par de parentesis, dentro de 
los cuales colocara los parametros (en caso de haber alguno) con los que funcionara la 
operacion. 

Mencione que podra convertir cualquier diagrama de secuencias en diagrama de colabo- 
raciones y viceversa. Por medio de esto podra representar la informacion de secuencia en 
un diagrama de colaboraciones. Para ello, agregara una cifra a la etiqueta de un mensaje, 
misma que correspondera a la secuencia propia del mensaje. La cifra y el mensaje se 
separan mediante dos puntos (:). 

La figura 10.1 le muestra la simbologfa del diagrama de colaboraciones. 

Aprovechemos la equivalencia de ambos tipos de diagramas. Para desarrollar los concep- 
tos de los diagramas de colaboraciones volveremos a ver los ejemplos que revisamos la 
hora anterior. Conforme lo haga, vera mas conceptos. 




Figura 10.1 

Simbologia del 
diagrama de 
co labor aciones. 




La GUI 

Este ejemplo es el caso mas directo. Un actor inicia la secuencia de interaction al oprimir 
una tecla, con lo que los mensajes ocurriran de manera secuencial. Tal secuencia (a partir 
de la hora anterior) es: 

1 . La GUI notifica al sistema operativo que se oprimio una tecla. 

2. El sistema operativo le notifica a la CPU. 

3. El sistema operativo actualiza la GUI. 

4. La CPU notifica a la tarjeta de video. 

5. La tarjeta de video envfa un mensaje al monitor. 

6. El monitor presenta el caracter alfanumerico en la pantalla, con lo que se hara 
evidente al usuario. 

La figura 10.2 muestra la forma de representar esta secuencia de interacciones en un 
diagrama de colaboraciones. El diagrama muestra la figura agregada que representa al 
usuario que inicia la secuencia, aunque esta figura no es parte de la simbologia de este 
diagrama. 



Figura 10.2 

Un diagrama de 
colaboraciones para 
el ejemplo de la GUI. 







Cambios de estado 

Puede mostrar los cambios de estado en un objeto en un diagrama de colaboraciones. 

En el rectangulo del objeto indique su estado. Agregue otro rectangulo al diagrama que 
haga las veces del objeto e indique el estado modificado. Conecte a los dos con una lfnea 
discontinua y etiquete la lfnea con un estereotipo «se toma». 

La figura 10.3 ilustra un cambio de estado para la GUI, que muestra que el estado de 
inicializacion se convierte en el estado operativo. 



Figura 10.3 

Un diagrama de 
colaboraciones puede 
incorporar cambios 
de estado . 




La maquina de gaseosas 

Las cosas se hacen mas interesantes cuando aplica las condiciones a una situacion real, 
como lo hizo en la hora anterior con la maquina de gaseosas. Iniciemos con la mejor 
situacion del caso de uso “Comprar gaseosa , donde la secuencia es. 

1 . El cliente inserta el dinero en la alcancfa que se encuentra en la fachada de la 
maquina. 

2. El cliente hace su election. 

3. El dinero viaja hacia el registrador. 

4. El registrador verifica si la gaseosa elegida esta en el dispensador. 

5. Dado que es la mejor situacion, asumimos que sf hay gaseosas, y el registrador 
actualiza su reserva de efectivo. 

6. El registrador hace que el dispensador entregue la gaseosa en la fachada de la 
maquina. 

El diagrama de colaboraciones es directo, como lo muestra la figura 10.4. 






Figura 10.4 



El diagrama de colabo- 
raciones para el 
mejor caso de 
“Comprar gaseosa ” 



insertar(alimentacion, seleccion) 




2:despachar(seleccion) 



Ahora, agreguemos el caso de “cantidad incorrecta de dinero”. El diagrama tiene que 
contabilizar varias condiciones: 

1 . El usuario ha introducido mas dinero que el necesario para la compra. 

2. La maquina cuenta con la cantidad adecuada de cambio. 

3. La maquina no tiene la cantidad correcta de cambio. 

Usted representara las condiciones de la misma forma en que las represento en el dia- 
grama de secuencias. Colocara la condicion entre corchetes, misma que se antecede a la 
etiqueta. Lo importante es coordinar las condiciones con la numeracion. 

Esto podrfa ser algo complicado, por lo que haremos el diagrama por secciones. Empe- 
zaremos con la condicion donde el usuario ha insertado mas dinero del indicado en el 
precio y el registrador cuenta con el cambio adecuado. Agregara el paso de la maquina 
al devolver el cambio al cliente, y agregara las condiciones entre corchetes. El paso que 
devuelve el cambio es una consecuencia del que verifica si hay cambio. Para indicar esto 
en el paso de devolver cambio utilizara el mismo numero del mensaje que verifica el 
cambio, y agregara un punto decimal y un uno. A esto se le conoce como anidacion. 

La figura 10.5 le muestra los detalles. 

^Que ocurre cuando la maquina no cuenta con el cambio correcto? Tendra que mostrar 
un mensaje que lo indique, devuelva el dinero y pida al usuario que inserte el importe 
correcto. Asi, la transaccion habra finalizado. 

Cuando agregue esta condicion, agregara una bifurcacion en el control de flujo. Numera- 
ra esta bifurcacion como un mensaje anidado. Dado que es el segundo mensaje anidado, 
habra un 2 luego del punto decimal. Finalmente, y debido a que la transaccion habra 
finalizado, hara clara esta situacion mediante la adicion de un estereotipo “transaccion fi- 
nalizada” en este mensaje, y otro en el mensaje que despacha la gaseosa. La figura 10.6 
presentara la situacion. 





Figura 10.5 

El diagrama de 
colaboraciones con 
parte de la situacion 
“monto de dinero 
inadecuado 



insertar(alimentacion, seleccion) 



1 :agregar( alimentacion, seleccion) 




4:despachar( seleccion) 



[alimentacion = precio) 2.1 : despachar(seleccion) [alimentacion > precio] 2.2: verificar 
[hay precio de entrada] 3.1 : despachar(seleccion) Cambio(alimentacion, precio) 



Figura 10.6 

El diagrama de 
colaboraciones 
“Comprar gaseosa ” 
con toda la situacion 
“monto de dinero 
inadecuado ” 



insertar (alimentacion, seleccion) 



4:despachar(seleccion) 



|:Despachador| - 




1 :agregar(alimentacion, seleccion) 



[alimentacion = precio] 2.1 : despachar(seleccion) [alimentacion > precio] 2.2: verifica 

[hay precio de entrada] 3.1 : despachar(seleccion) Cambio(alimentacion, precio) 



En el taller, al fmalizar esta hora, habra un ejercicio que le pedira que complete el diagram; 
de colaboraciones mediante la adicion de la situacion “no hay gaseosa”. 

Creadon de un objeto 

Para mostrar la creation de objetos, volvere al caso de uso “Crear propuesta” de la firma 
de consultorfa. Una vez mas, la secuencia que modelara sera: 

1 . El consultor buscara en el area de almacenamiento centralizada de la red una pro- 
puesta adecuada en la cual basarse. 

2. Si el consultor localiza una propuesta adecuada, la abrira y en el proceso abrira la 
aplicacion de oficina. El consultor guardara el archivo bajo un nuevo nombre, con 
lo que creara un nuevo archivo para la nueva propuesta. 

3. Si el consultor no encuentra una propuesta, abrira la aplicacion de oficina y generara 
un nuevo archivo. 








4. A1 trabajar en la propuesta, el consultor utilizara los componentes de la aplicacion 
de oficina. 

5. Cuando el usuario finalice la propuesta, la guardara en el area de almacenamiento 
centralizada. 

Para mostrar la creacion de un objeto, agregara un estereotipo “crear” al mensaje que 
genera al objeto. 

Una vez mas, utilizara instrucciones “si” (if) y mensaje anidados. Tambien trabajara 
con un ciclo “mientras” (while). Como en el diagrama de secuencias, para representar 
a “mientras”, colocara esta condicion entre corchetes y antecedera al del lado izquierdo 
con un asterisco. 

La figura 10.7 le muestra este diagrama de colaboraciones completo con la creacion del 
objeto y “mientras”. 




Algunos conceptos mas 

Aunque ha visto algunas bases, no ha visto todo lo relacionado con los diagramas de 
colaboraciones. Los conceptos en esta section son un poco esotericos, pero podnan serle 
utiles en sus esfuerzos para analizar sistemas. 




Varios objetos receptores en una dase 

En ocasiones un objeto envia un mensaje a diversos objetos de la misma clase. Por ejem- 
plo: un profesor le pide a un grupo de estudiantes que entreguen una tarea. En el diagrama 
de colaboraciones, la representacion de los diversos objetos es una pila de rectangulos 
que se extienden “desde atras”. Agregara una condicion entre corchetes precedida por un 
asterisco para indicar que el mensaje ira a todos los objetos. La figura 10.8 le muestra los 
detalles. 



Figura 10.8 

Un objeto que envia 
un mensaje a diversos 
objetos de una clase . 




En algunos casos, el orden del mensaje enviado es importante. Por ejemplo, un empleado 
bancario dara servicio a cada cliente conforme fue llegando a la fila. Esto lo representara 
con un “mientras” cuya condicion implicara orden (como en “posicion en la fila = 1 ... n”; 
junto con el mensaje y la pila de rectangulos (vea la figura 10.9). 



Figura 10.9 

Un objeto que envia 
un mensaje a varios 
otros en un orden 
especifico. 




Representacion de los resultados 

Un mensaje podrfa ser una petition a un objeto para que realice un calculo y devuelva 
un valor. Un objeto Cliente podrfa solicitar a un objeto Calculadora que calcule el precio 
total que sea la suma del precio de un elemento y el impuesto. 

El UML le da una sintaxis para representar esta situation. Debera escribir una expresion 
que tenga el nombre del valor devuelto a la izquierda, seguido de a continuation el 
nombre de la operation y las cantidades con que opera para producir el resultado. En este 
ejemplo, la expresion podrfa ser precioTotal := calcular(precioElemento, impuesto). 

La figura 10.10 le muestra la sintaxis de un diagrama de colaboraciones. 




Figura 10.10 

Un dia grama de 
colaboraciones que 
incluye la sintaxis 
de un resultado. 





Termino Nuevo 



A la parte que esta a la derecha de la expresion se le conoce 
como firma del mensaje. 



Objetos activos 



Termino Nuevo 



En algunas interacciones, un objeto especifico controla el flujo. Este objeto 
activo puede enviar mensajes a los objetos pasivos e interactuar con otros 
objetos activos. En una biblioteca, un bibliotecario relaciona las peticiones a partir de un 
patron, verifica la information de referenda en una base de datos, devuelve una respuesta 
al peticionario, asigna personas para reabastecer los libros, entre otras cosas. Un biblio- 
tecario tambien interactua con otros que realicen las mismas operaciones. Al proceso de 
que dos o mas objetos activos hagan sus tareas al mismo tiempo, se le conoce como con- 
currencia. 



El diagrama de colaboraciones representa a un objeto activo de la misma manera que a 
cualquier otro objeto, excepto que su borde sera grueso y mas oscuro. (Vea la figura 10. 1 1 .) 



Figura 10.11 

Un objeto activo 
controla el flujo 
en una secuencia. 

Se representa como 
un rectangulo con un 
borde grueso en negro. 




Sincronization 

Otro caso con el que se puede encontrar es que un objeto solo puede enviar un mensaje 
despues de que otros mensajes han sido enviados. Es decir, el objeto debe “sincronizar” 
todos los mensajes en el orden debido. 





Un ejemplo aclarara esto. Suponga que sus objetos son personas en un corporativo, 
y que estan ocupados en la campana de un nuevo producto. He aqui la secuencia de 
interacciones: 

1 . El vicepresidente de comercializacion le pide al de ventas que cree una campana 
para un producto en particular. 

2. El vicepresidente de ventas crea la campana y la asigna al gerente de ventas. 

3. El gerente de ventas instruye a un agente de ventas para que venda el producto de 
acuerdo con la campana. 

4. El agente de ventas hace llamadas para vender el producto a los clientes en potencia. 

5. Luego de que el vicepresidente de ventas ha dado la comision y el gerente de ven- 
tas ha expedido la directiva (esto es, cuando se han completado los pasos 2 y 3), un 
especialista en relaciones publicas de la corporacion hara una llamada al periodico 
local y colocara un anuncio de la campana. 

^C6mo representara la position del paso cinco en la secuencia? Nuevamente, el UML le 
da una sintaxis. En lugar de anteceder este mensaje con una etiqueta numerica, lo ante- 
cederd con una lista de mensajes que tendrdn que completarse antes de que se realice el 
paso cinco. La lista de elementos se separard mediante una coma, y finalizara con una 
diagonal. La figura 10.12 le muestra el diagrama de colaboraciones en este ejemplo. 



Figura 10.12 

La sincronizacion 
de mensajes en 
un diagrama de 
colaboraciones. 




Adiciones al panorama 

Ahora podra agregar el diagrama de colaboraciones a su panorama del UML. Es otro 
elemento de comportamiento, como se aprecia en la figura 10.13. 








Figura 10.13 

El panorama del 
UML , que incluye 
al diagrama de 
colaboraciones . 
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Resumen 

Un diagrama de colaboraciones es otra forma de presentar la information en un dia- 
grama de secuencias. Ambos tipos de diagramas son semanticamente equivalentes y se 
recomienda usar ambos cuando construya el modelo de un sistema. El diagrama de 
secuencias se organiza de acuerdo al tiempo, y el de colaboracion de acuerdo al espacio. 

El diagrama de colaboraciones muestra las asociaciones entre objetos, asi como los 
mensajes que pasan de un objeto a otro. El mensaje se representa con una flecha junto 
a la linea de asociacion, y una etiqueta numerada que muestra el contenido del mensaje. 
El numero representa el tumo del mensaje en la secuencia. 

Las condicionales se representan como antes, mediante la colocation de la instruction 
condicional entre corchetes. Para representar un ciclo “mientras”, anteceda al corchete 
izquierdo con un asterisco. 

Algunos mensajes provienen de otros. El esquema de numeracion de las etiquetas repre- 
senta esto de forma muy similar a los manuales tecnicos que muestran sus encabezados 
y subtftulos: con un sistema de numeracion que utiliza puntos decimales para representar 
los niveles del anidamiento. 





Los diagramas de colaboraciones le permiten modelar varios objetos receptores en una 
clase, ya sea que los objetos reciban o no los mensajes en un orden especifico. Tambien 
podra representar objetos activos que controlen el flujo de los mensajes, asi como los 
mensajes que se sincronizan con otros. 

Preguntas y respuestas 

P ^Realmente tengo que incluir a ambos diagramas (el de colaboraciones y el de 
secuencias) en la mayoria de los modelos UML que genere? 

R Se recomienda hacerlo. Ambos tipos de diagramas podran estimular diversas ideas 
de los procesos durante el segmento de analisis en el proceso de desarrollo. El 
diagrama de colaboraciones clarifica las relaciones entre los objetos debido a 
que incluye los vfnculos entre ellos. El de secuencia se enfoca en la secuencia de 
las interacciones. A su vez, la organization de su cliente podrfa incluir personas 
cuya idea de los procesos podrfa diferir entre ellos. Cuando tenga que presentar 
su modelo, un tipo de diagrama podrfa comprenderse mejor para ciertas personas. 



Taller 

Ahora que ha comprendido los diagramas de secuencias y a sus hermanos, los de colabo- 
racion, pruebe y fortalezca su conocimiento con el cuestionario y los ejercicios. Como 
siempre, vera las respuestas en el Apendice A, “Respuestas a los cuestionarios”. 

Cuestionario 

1 . ^Como representa a un mensaje en un diagrama de colaboraciones? 

2. ^Como mostrarfa information secuencial en un diagrama de colaboraciones? 

3. ^Como mostrarfa los cambios de estado? 

4. ^Que se entiende por la “equivalencia semantica” de dos tipos de diagramas? 

Ejercicios 

1. En el ejemplo de la maquina de gaseosas, solo mostre un diagrama de colabora- 
ciones equivalente al diagrama de secuencias de instancia de la situacion “importe 
incorrecto”. Cree un diagrama de colaboraciones que corresponda al diagrama 
de secuencias generico de la hora 9 para el caso de uso “Comprar gaseosa”. Esto 
es, agregue la situacion “Gaseosa agotada” al diagrama de colaboraciones de la 
figura 10.5. 




2. En el diagrama de colaboraciones del caso de uso “Crear propuesta”, el consultor 
busca en el area central de almacenamiento una propuesta adecuada para volverla 
a utilizar. Imagine a “buscar” como un mensaje enviado para buscar en una secuen- 
cia de archivos, y utilice las tecnicas de modelado de la section “Algunos conceptos 
mas” para cambiar el diagrama de colaboraciones en la figura 10.6. 




Hora 1 1 



Diagramas 

Ahora veremos un tipo de diagrama que podrfa parecerle familiar, este 
diagrama le muestra los pasos en una operation o proceso. 

En esta hora se trataran los siguientes temas: 

• Que es un diagrama de actividades 

• Aplicacion de los diagramas de actividades 

• Marcos de responsabilidad 

• Adiciones al panorama 

Si alguna vez ha tornado algun curso basico de programacion, ya conocera 
los diagramas de flujo. Siendo uno de los primeros modelos visuales que se 
aplicaron a la computation, el diagrama de flujo muestra una secuencia de 
pasos, procesos, puntos de decision y bifurcaciones. A los programadores 
novatos se les invita a que utilicen este diagrama para conceptualizar pro- 
blemas y derivar sus soluciones. La idea es convertir al diagrama de flujo 




en la base del codigo. Con sus diversas caracterfsticas y tipos de diagramas, el UML es en 
cierta medida un diagrama de flujo con esteroides. 

El diagrama de actividades del UML, tema de esta hora, es muy parecido a los viejos 
diagramas de flujo. Le muestra los pasos (conocidos como actividades) asi como puntos 
de decision y bifurcaciones. Es util para mostrar lo que ocurre en un proceso de negocios 
u operacion. Los encontrara como parte integral del analisis de un sistema. 

Que es un diagrama de actividades 

Para empezar, un diagrama de actividades ha sido disenado para mostrar una vision 
simplificada de lo que ocurre durante una operacion o proceso. Es una extension de 
un diagrama de estados, mismo que ya conocio. El diagrama de estados muestra los es- 
tados de un objeto y representa las actividades como flechas que conectan a los estados. 
El diagrama de actividades resalta, precisamente, a las actividades. 

A cada actividad se le representa por un rectangulo con las esquinas redondeadas (mas 
angosto y ovalado que la representacidn del estado). El procesamiento dentro de una 
actividad se lleva a cabo y, al realizarse, se continua con la siguiente actividad. Una flecha 
representa la transicion de una a otra actividad. Al igual que el diagrama de estados, el de 
actividad cuenta con un punto inicial (representado por un circulo relleno) y uno final 
(representado por una diana). 

La figura 11.1 le muestra el punto inicial y final, asi como dos actividades y una transicion. 



Figura 11.1 

Transicion de una 
actividad a otra. 







Decisiones, decisiones, decisiones 

Casi siempre una secuencia de actividades llegara a un punto donde se realizara alguna 
decision. Ciertas condiciones le llevaran por un camino y otras por otro (pero ambas son 
mutuamente exclusivas). 

Podra representar un punto de decision de una de dos formas: la primera es mostrar las 
rutas posibles que parten directamente de una actividad y la segunda es llevar la transi- 
tion hacia un rombo — reminiscencias del simbolo de decision en un diagrama de 
flujo — y que de alii salgan las rutas de decision (como usuario de los antiguos diagramas 
de flujo, prefiero la segunda option). De cualquier forma, indicara la condition con una 
instruction entre corchetes junto a la ruta correspondiente. La figura 1 1 .2 le muestra las 
posibilidades. 



Figura 11.2 

Dos formas de mostrar 
una decision. 
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^Despertar^ 




[hambrientoLAA. [inapetente] 



^Desayunar^ ^ 



Volver a dormir 



Rutas concurrentes 

Conforme modele actividades tendra la oportunidad de separar una transicion en dos 
rutas que se ejecuten al mismo tiempo (es decir, de forma concurrente) y luego se reunan. 
Para representar esta division, utilizara una linea gruesa perpendicular a la transicion y 
las rutas partiran de ella. Para representar la reincorporacion, ambas rutas apuntaran a 
otra linea gruesa (vea la figura 1 1 .3). 












Figura 11.3 

Representation 
de una transition 
que se bifurca en 
dos rutas que se 
ejecutan de forma 
concurrente y, luego, 
se reincorporan. 




Indicaciones 

Durante una secuencia de actividades, es posible enviar una indication. Cuando se 
reciba, la indication provocara que se ejecute una actividad. El simbolo para enviar una 
indication es un pentagono convexo, y el que la recibe es un pentagono concavo. La 
figura 1 1 .4 le ayudara a clarificar la idea. 




En terminos del UML el pentagono convexo simboliza al envfo de un evento ; 
el concavo simboliza la reception del evento. 







Figura 11.4 

Envio y reception 
de una indication . 




Aplicacion de los diagramas de actividades 

Veamos algunos ejemplos. Para empezar, diagramara una operacion y posteriormente 
un proceso. 

Una operacion: Fibs 

^Habia visto la siguiente serie de numeros? 1, 1, 2, 3, 5, 8, 13,.... se conoce como la 
“serie de Fibonacci”, pues este matematico medieval la escribio hace unos 800 anos. 
Cada numero es un “fib”, asi que el primer fib [o fib(l)] es 1, fib(2) es 1, fib(3) es 2, 
y asi sucesivamente. La regia de cada fib, excepto en los dos primeros, es la suma del 
anterior par de fibs, por ejemplo, fib(8) tendrfa un valor de 21. 

Suponga que una de sus clases es una calculadora, y que una de sus operaciones fuese la 
de calcular el enesimo fib y mostrarlo. A esta operacion podrfa llamarla calcularFib(n). 
Creemos un diagrama de actividades que modele a esta operacion. 

Requerira algunas variables como son: un contador para llevar un control para verificar si 
se ha llegado al enesimo fib, una variable para conglomerar los resultados, y dos mas 
para almacenar dos fibs que tendra que sumar entre si. La figura 1 1.5 le muestra el diagrama 
de actividades que realizarfa la tarea. 








Figura 11.5 

Un diagrama de 
actividades para 
calcularFib(n), 
una operation que 
calcula el enesimo 
numero de Fibonacci. 




Proceso de creation de un documento 

Ahora volvamos nuestra atencion de una operation a un proceso. Imagine las actividades 
necesarias para utilizar una aplicacion de oficina para crear un documento. Una posible 
secuencia podrfa ser: 

1. Abrir la aplicacion para procesamiento de textos. 

2. Crear un archivo. 

3. Guardar el archivo con un nombre unico en una carpeta. 

4. Teclear el documento. 

5. Si se necesitan ilustraciones, se abre la aplicacion relacionada, se generan los 
graficos y se colocan en el documento. 

6. Si se necesita una hoja de calculo, se abre la aplicacion relacionada, se crea la hoja 
correspondiente y se coloca en el documento. 









7. Se guarda el archivo. 

8. Se imprime el documento. 

9. Se sale de la aplicacion de oficina. 

El diagrama de actividades de esta secuencia aparece en la figura 1 1 .6. 



Figura 11.6 

Un diagrama de 
actividades para el 
proceso de creacion 
de un documento. 














Marcos de responsabilidad 

Uno de los aspectos mas utiles del diagrama de actividades es su facultad para expandirse 
y mostrar quien tiene las responsabilidad en un proceso. 

Veamos el caso de una firma de consultorfa y el proceso de negociacion involucrado en 
una junta con un cliente. Las actividades podrfan ocurrir corao sigue: 

L Un vendedor hace una llamada al cliente y concierta una cita. 

2. Si la cita es en la oficina del consultor, los tecnicos corporativos preparardn una 
sala de conferencias para hacer una presentacion. 

3. Si es en la oficina del cliente, un consultor preparara una presentacion en una 
laptop. 

4. El consultor y el vendedor se reuniran con el cliente en el sitio y a la hora 
convenidos. 

5. El vendedor crea una minuta. 

6. Si la reunion ha planteado la solucion de un problema, el consultor creara una 
propuesta y la enviard al cliente. 

Un diagrama de actividades estandar podna lucir como en la figura 1 1.7. 
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El diagrama de actividades agrega la dimension de visualizar responsabilidades. 
Para ello, separara el diagrama en segmentos paralelos conocidos como marcos 
de responsabilidad . Cada marco de responsabilidad muestra el nombre de un responsable 
en la parte superior, y presenta las actividades de cada uno. Las transiciones pueden lle- 
varse a cabo de un marco a otro. La figura 1 1.8 muestra la version con marcos de respon- 
sabilidad del diagrama de actividades de la figura 1 1.7. 




Ambos diagramas de actividades de "Reunion con un cliente nuevo" muestran 
la creacion de una propuesta como actividad. En cada caso, tal actividad podna 
tener una nota adjunta que cite al diagrama de actividades para la creacion 
del documento. 





Figura 11.7 



Un diagrama de activi- 
dades para el proceso 
de negociacion en una 
junta con un cliente. 




[no se plantea 
un problema] 










Figura 11.8 

La version con marcos 
de trabajo de dia- 
grama de actividades 
de la figura 11.7 que 
muestra quien es el 
responsable de cada 
actividad. 
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Diagramas hibridos 

Recordemos el diagrama de actividades para la creacion de un documento. Podra depur 
la actividad de la impresion de un documento. En lugar de solo mostrar una actividad 
“Imprimir documento ’, podria ser un poco mas especffico. La impresion se realiza dadc 
que una senal dentro del archivo de documento se transmite desde la aplicacion para el 
procesamiento de textos a la impresora, misma que la recibe y la imprime. 

La figura 1 1.9 le muestra que podra representar esto con los sfmbolos para la transmisic 
y recepcion de senates, junto con un objeto Impresora que reciba al sfmbolo y realice si 
tarea de impresion. Este es un ejemplo de diagrama hfbrido, dado que contiene sfmbolo 
que normalmente asociarfa con diferentes tipos de diagramas. 







Figura 11.9 

La depuracion de la 
actividad “ Imprimir 
documento ” nos 
otorga un diagrama 
hibrido. 















He aqui otra posibilidad de diagrama hibrido: podra mostrar un diagrama de actividades 
para realizar una operacion dentro de un simbolo de objeto, y mostrar al objeto que re- 
cibe una petition para ejecutar la operacion. Suponga que modelo al objeto Calculadora, 
el cual calcula los numeros de Fibonacci. Los desarroll adores podrian encontrar util que 
usted lo representara con un diagrama hibrido como el de la figura 1 1.10. 



Figura 11.10 

Un diagrama hibrido 
puede mostrar un dia 
grama de actividades 
dentro de un objeto . 



:Calculadora 




Adiciones al panorama 

La figura 11.11 muestra el panorama del UML, donde se incluye el diagrama de activi- 
dades. Este diagrama es un elemento de comportamiento. 





Elementos estructurales 



Figura 11.11 

El panorama del 
UML ahora incluye 
al diagrama de 
actividades. 
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Resumen 

El diagrama de actividades del UML es muy parecido a un diagrama de flujo. Muestra 
los pasos, puntos de decision y bifurcaciones. Este tipo de diagrama es util para repre- 
sentar las operaciones de un objeto y los procesos de negocios. 

El diagrama de actividades es una extension del diagrama de estados. Los diagramas de 
estados destacan los estados y representan actividades como flechas entre los estados. Los 
de actividad se enfocan en las actividades. Cada actividad se representa como un rectan- 
gulo con esquinas redondeadas, mas ovalados en apariencia que la representacion de un 
estado. El diagrama de actividades utiliza los mismos sfmbolos que el de estados para los 
puntos de inicio y final. 







Cuando una ruta se divide en dos o mas, tal dispersion se representa con una lfnea gruesa 
perpendicular a las rutas, mismas que se reunen en una lfnea similar. Dentro de un dia- 
grama de secuencias puede mostrar una serial, cuya transmision se representa con un 
pentagono convexo, y la recepcion con uno concavo. 

En un diagrama de actividades, puede representar las actividades de acuerdo con la 
responsabilidad asignada. Esto lo harfa con marcos de responsabilidad, mismos que son 
segmentos paralelos que corresponden a los responsables de realizar cada tarea. 

Es posible combinar al diagrama de actividades con sfmbolos de otros diagramas con lo 
que se produciran diagramas hfbridos. 

Preguntas y respuestas 

P Esta es otra de esas preguntas de “^Realmente lo necesito?”. Con todo lo que 
nos muestra un diagrama de estados, ;,realmente necesito los de actividad? 

R Yo le recomiendo que incluya los diagramas de actividades en su analisis. Pueden 
poner en claro algunos procesos y operaciones para usted y sus clientes. Tambien 
son muy utiles para los desarrolladores. Es muy probable que un buen diagrama de 
actividades sea de gran utilidad para que un desarrollador codifique una operacion. 

P Ha mostrado dos tipos de diagramas hfbridos. <,E1 UML establece limitacione: 
en los tipos de hfbridos que puede crear? 

R No, en absoluto. El UML no intenta ser restrictive. Aunque tiene algunas reglas 
sintacticas, la idea es que los analistas generen un modelo que transmita una idea 
consistente a los clientes, disenadores y desarrolladores; no la de satisfacer cenidaj 
reglas lingiifsticas. Si puede generar un diagrama hfbrido que ayude a que todos lo 
involucrados comprendan un sistema, hagalo. 



Taller 

El cuestionario y los ejercicios le haran razonar los diagramas de actividades y su utilidac 
Las respuestas se encuentran en el Apendice A, “Respuestas a los cuestionarios . 

Cuestionario 

1. ^Cuales son las dos formas de representar a un punto de decision? 

2. c Que es un marco de responsabilidad? 

3. ^Como representarfa la transmision y recepcion de una indication? 



Ejercicios 

1 . Cree un diagrama de actividades que muestre el proceso que realizarfa al encender 
su automovil. Empiece al colocar la Have en el switch, fmalice con el motor en 
funcionamiento y tome en cuenta todo lo que haria si el motor no arrancara de 
inmediato. 

2. ^Que podria agregar al diagrama de actividades en el proceso de negociacion de la 
junta con un cliente nuevo? 

3. Si distribuye tres piedras de modo que una de ellas se ubique en una fila y las otras 
dos en otra, formarian un triangulo. Si hace lo mismo con seis piedras, de manera 
que se ubiquen: una en una fila, dos en la siguiente, y tres en la ultima, tambien 
formarian un triangulo. Por ello, a los numero 3 y 6 se les conoce como numeros 
triangulares. El siguiente numero triangular es 10, el que le sigue es 15, y asi por 
el estilo. El primer numero triangular es 1. Cree dos diferentes diagramas de activi- 
dades para un proceso que calcule el enesimo numero triangular. Para uno, inicie 
con n y continue en orden regresivo. Para el otro, inicie con 1 y continue en orden 
progresivo. 

4. He aqui un ejercicio para quienes les gustan las matematicas. Si se sintio a gusto 
con el ejercicio 3, tal vez le guste este otro. Si no, tan solo continue con la siguien- 
te hora ({podria intentar diagramar lo que dije en las dos ultimas oraciones!). En la 
geometria coordinada, se representa un punto en el espacio al mostrar su posicion 
x y y. Por ello, puede decir que la ubicacion del punto 1 es XI, Yl. La del punto 2 
es X2, Y2. Para encontrar la distancia entre estos puntos, eleve al cuadrado X2-X1 
y luego Y2-Y1. Sume ambos cuadrados y calcule la raiz cuadrada de la suma. Cree 
un diagrama de actividades para una operation distancia (XI, Yl, X2, Y2) que 
localice la distancia entre dos puntos. 




Hora 







Diagramas 
de componentes 

En las horas anteriores ha visto diagramas que tratan temas conceptuales. 
Un diagrama de clases representa un concepto, es decir, la abstraction de 
elementos que confluyen en una categorfa; un diagrama de estados tambien 
representa un concepto, como son los cambios en el estado de un objeto. 

Ahora vera el uso de un diagrama que es algo distinto a los que ha visto, y 
aprendera lo correspondiente a un diagrama UML que representa a una 
entidad real: un componente de software. 

En esta hora se trataran los siguientes temas: 

• Que es un componente 

• Componentes e interfaces 

• Que es un diagrama de componentes 

• Aplicacion de los diagramas de componentes 

• Diagramas de componentes en el panorama del UML 



Que es un componente 

Un componente de software es una parte ffsica de un sistema, y se encuentra en la compu- 
tadora, no en la mente del analista. ^Que puede tomarse como componente? Una tabla, 
archivo de datos, ejecutable, biblioteca de vinculos dinamicos, documentos y cosas por el 
estilo. 

^Cual es la relacion entre un componente y una clase? Imagine a un componente como la 
personification en software de una clase. La clase representa una abstraction de un con- 
junto de atributos y operaciones. Un importante punto por recordar de los componentes y 
clases es que un componente puede ser la implementation de mas de una clase. 

Si el componente se encuentra en una computadora y es la parte funcional del sistema, 
<?,para que preocuparse por el? Tendra que modelar componentes y sus relaciones para que: 

1. Los clientes puedan ver la estructura del sistema finalizado. 

2. Los desarrolladores cuenten con una estructura con la cual trabajar en adelante. 

3. Quienes escriban las notas tecnicas y la documentation puedan entender de que 
escribiran. 

4. Usted se aliste para volver a utilizar los componentes. 

Exploremos el ultimo punto. Uno de los aspectos mas importantes de los componentes 
es el potencial que tienen de volver a ser utilizados. Con las necesidades actuates de los 
negocios de soluciones rapidas, entre mas rapido presente un sistema para production, 
mayor sera su competitividad. Si puede crear un componente para un sistema y puede 
volver a utilizarlo en otro, usted habra contribuido a esa competitividad. Tomese el 
tiempo y esfuerzo para modelar un componente que lo ayude a que esta reutilizacion 
pueda llevarse a cabo. 

Recordaremos la reutilizacion al final de la siguiente section. 

Componentes e interfaces 

Cuando trate con los componentes, tendra que tratar con sus interfaces; al tratar el tema 
de las clases y los objetos, hable de las interfaces. Como recordara en la hora 2, “Orienta- 
tion a objetos”, un objeto oculta al mundo exterior lo que hace (lo que se conoce como 
encapsulation , encapsulamiento u ocultamiento de information). El objeto tiene que 
presentar un “rostro” al mundo exterior, para que los demas objetos (incluso, potencial- 
mente, los humanos) puedan pedirle que ejecute sus operaciones. A este “rostro” se le 
conoce como interfaz del objeto. 

Di mayores detalles de esta idea en la hora 5, “Agregacion, composition, inter- 
faces y relacion”. Como lo mencione en su momento, diversas clases podrian 
no estar relacionadas con una clase principal (como en la herencia), pero sus acciones po- 
drian incluir algunas de las mismas operaciones con las mismas firmas. Podra reutilizar 
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este conjunto de operaciones de clase en clase. La interfaz es la construction UML que 
le permite hacer esto. Una interfaz es un conjunto de operaciones que especifica algo 
respecto al comportamiento de una clase. Imagine a una interfaz como una clase que solo 
contiene operaciones (no atributos). Para resumir: la interfaz es un conjunto de opera- 
ciones que presenta una clase a otras. 

Al tratar las interfaces en la hora 5, tambien mencione que la relation entre una clase 
y su interfaz se conoce como realization. 



;Un momento! Pareceria que modelar una interfaz es la practica de modelar un concepto. 
Al principio de esta hora, le dije que cuando modele un componente no sera algo concep- 
tual, dado que se encontrara en una computadora. <,Donde esta la conexion? 



En si, una interfaz puede ser ffsica o conceptual. La interfaz que utiliza una clase es la 
misma que la que utiliza su implementation de software (un componente). Como mode- 
lador, esto significa que la de la misma forma en que represente una interfaz para una 
clase representara una interfaz para un componente. Aunque la simbologfa del UML dis- 
tingue entre una clase y un componente, no hace distincion entre una interfaz conceptual 
y una ffsica. 
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Hay un punto importante a este respecto: solo podra ejecutar las operaciones 
de un componente a traves de su interfaz. De la misma manera que en el caso 
de una clase y su interfaz, la relation entre un componente y su interfaz se conoce como 
realization. 



Hay otro punto por destacar: un componente puede hacer disponible su interfaz 
para que otros componentes puedan utilizar las operaciones que contiene. Es 
decir, un componente puede acceder a los servicios de otro componente. El componente 
que proporciona los servicios se dice que provee una interfaz de exportation. Al que 
accede a los servicios se dice que utiliza una interfaz de importation. 
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Sustitucion y reutilizacion 

Las interfaces se destacan de forma importante en los conceptos primordiales de sustitu- 
cion y reutilizacion de componentes. Puede sustituir un componente con otro si el nuevo 
contiene las mismas interfaces que el anterior. Podra reutilizar un componente en otro 
sistema si este puede acceder al componente reutilizado mediante sus interfaces. Puede 
disenar un componente para ser reutilizado en proyectos de desarrollo a lo largo de su 
empresa si quiere depurar sus interfaces para que un amplio rango de componentes 
puedan acceder a ellos. 

Es aquf donde son utiles las interfaces en el modelado. Puede simplificarse la vida de un 
desarrollador que intente sustituir o reutilizar un componente si la information de su in- 
terfaz se encuentra disponible como un modelo. Si no, el desarrollador tendra que pasar 
por el largo proceso de hacer un seguimiento del codigo. 





Tipos de componentes 

Conforme avance en su carrera como modelador, se encontrara con tres tipos de 
componentes: 

1. Componentes de distribution, que conforman el fundamento de los sistemas ejecu- 
tables (por ejemplo, DLL, ejecutables, controles ActiveX y Java Beans). 

2. Componentes para trabajar en el producto , a partir de los cuales se han creado los 
componentes de distribucion (como archivos de base de datos y de codigo). 

3. Componentes de ejecucion , creados como resultado de un sistema en ejecucion. 

Si es usted un usuario de Windows, encontrara ejemplos de los tres tipos de componentes 
cuando utilice la ayuda, aunque tal vez no lo sepa. El componente de distribucion es el 
archivo .HLP (Archivo de Ayuda): Cuando haga clic en uno, se abrira el cuadro de dia- 
logo de los temas de la ayuda y empezara a buscar el tema que elija. La primera vez 
que haga clic en la ficha Buscar, vera una pequena animation que le indicara que se esta 
creando un fndice. Un archivo .CNT (tema de contenido) describe el esquema del con- 
tenido. Dado que este archivo le ayuda a crear un componente de distribucion (puede 
utilizar la pagina de fndice por siempre), es un componente para trabajar en el producto. 
A su vez, el fndice creado se encuentra en un archivo .FTS (busqueda de texto completo). 
Finalmente, la primera vez que abra la ayuda, se creara un archivo .GID (fndice general), 
que es resultado de un analisis del sistema de ayuda de Windows que agiliza el acceso a 
los temas del archivo de ayuda. Con ello, los archivos .FTS y .GID son componentes de 
ejecucidn. 

Que es un diagrama de componentes 

Un diagrama de componentes contiene, obviamente, componentes, interfaces y relaciones. 
Tambien pueden aparecer otros tipos de sfmbolos que ya haya visto. 

Representation de un componente 

El sfmbolo principal de un diagrama de componentes es un rectangulo que tiene otros 
dos sobrepuestos en su lado izquierdo. La figura 12.1 le muestra este sfmbolo. Debe 
colocar el nombre del componente dentro del sfmbolo. El nombre es una cadena. 

Figura 12.1 

El simbolo que 
representa a un 
componente . 





La figura 12.2 le muestra que si el componente es miembro de un paquete, puede utilizar 
el nombre del paquete como prefijo para el nombre del componente. Tambien puede 
agregar information que muestre algun detalle del componente. 



Figura 12.2 

Adicion de informa- 
tion al simbolo del 
componente. 



rz 

t— herramientas:: 

* — calculadora.java 

T — 



procesadorTextos.exe 

Clases: 

ProcesadorTextos 

VerificadorOrtografico 

ContadorPalabras 



El simbolo a la derecha de la figura 12.2 le muestra las clases que implementa un com- 
ponente en particular. La figura 12.3 le muestra otra forma de hacer esto, aunque esta 
tecnica por lo general desordena el diagrama. Vea las relaciones de dependencia entre el 
componente y las clases. 



Figura 12.3 

Simbolos de las rela- 
tione s entre un com- 
ponente y las clases 
que implementa. 




Como representar las interfaces 

Existen dos formas para representar a un componente y sus interfaces: la primera mues- 
tra la interfaz como un rectangulo que contiene la informacion que se le relaciona, se 
conecta al componente por la linea discontinua y una punta de flecha representada por 
un triangulo sin rellenar que visualiza la realization (vea la figura 12.4). 



Figura 12.4 

Puede representar a 
una interfaz como un 
rectangulo con infor- 
mation, conectado al 
componente por una 
flecha de realization. 
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La figura 12.5 le muestra la segunda forma de representar a un componente y sus interfa- 
ces; esta forma es representativa, ya que representara la interfaz como un pequeno cfrculo 
que se conecta al componente por una li'nea continua. En este contexto, la lfnea representa 
la relacion de realizacion (compare a las figuras 12.4 y 12.5 con las figuras 5.6 y 5.7). 

Figura 12.5 

Puede representar a 
una interfaz como un 
pequeno ci'rculo , conec 
tado al componente 
por una h'nea continua 
que, en este contexto, 
se interpreta como 
realizacion. 

Ademas de la realizacion, puede representar a la dependencia, que es la relacion entre 
un componente y una interfaz de importation. Como recordara, la dependencia se vis- 
1 umbra como una lfnea discontinua con una punta de flecha. Puede mostrar la realizacion 
y la dependencia en el mismo diagrama, como se ve en la figura 12.6. 

Figura 12.6 

Una interfaz que rea- 
liza un componente y 
otra de la que depende 






Aplicacion de los diagramas de componentes 

Algunos ejemplos le ayudaran a empezar a usar los diagramas de componentes. El prime- 
ro es un modelo de una pagina Web que representa a un componente Java. El siguiente 
tambien es un modelo de una pagina Web pero este utiliza controles ActiveX. Finalizara 
con un modelo de un paquete de Microsoft conocido como PowerToys. Este paquete, que 
puede obtener del sitio de Microsoft, le permite modificar aspectos de Win32. 

Una pagina Web con un subprograma Java 

Este ejemplo modela un programa tornado del excelente y entretenido libro de Rogers 
Cadenhead llamado Aprendiendo programacion con Java 1.1 en 24 horas (Prentice Hall 







Hispanoamericana, 1997). El ejemplo aparece en la hora 22, “Escriba un juego para 
Web”. Rogers muestra como generar un applet (o subprograma) que ejecuta el juego 
de dados “Craps” en una pagina Web, y utiliza una clase llamada “Die” (para crear los 
dados) de la hora 21, “A jugar con Java”. Para ver los detalles del codigo, tendra que leer 
el libro. Aquf solo nos concentraremos en los componentes. 
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Un applet es un pequeno programa hecho en Java que fun- 
ciona en una pagina Web. 



La pagina Web se llama Craps.html. El codigo fuente del applet se encuentra en el 
archivo Craps.java, y el codigo objeto es el archivo Craps.class. El codigo fuente de la 
clase Die se encuentra en Die.java y el codigo objeto en Die.class. Los cinco archivos se 
encuentran en el mismo directorio — que llamaremos Tirodedados (que no es el nombre 
que Roger le dio) — . 

Craps.html depende, obviamente, de Craps.class y Die.class. Cada archivo .class es un 
componente y cada uno es la implementation de una clase. Lo que no es muy obvio (ten- 
drfa que ver el codigo fuente para descubrirlo) es que tanto Craps.java como Die.java 
importan (utilizan las clases de) java.awt, un grupo de clases que muestran y controlan la 
GUI (el “awt” significa: “Conjunto de herramientas abstractas para manejar ventanas”). 




En el contexto de Java, la importation permite al desarrollador utilizar solo el 
nombre de una operacion cuando la escribe en un programa, en lugar de uti- 
lizar toda la ruta de la operacion (que podria ser muy larga). La importacion 
no "incrusta" una clase en otra. Tan solo permite escribir algo mas corto. 



Craps.java es un applet, y por ello se hereda desde la clase java.applet. Applet. Finalmente, 
Craps.java importa a java.awt.event e implementa una interfaz ActionListener (para 
responder a los eventos generados por el usuario, como hacer clic con el raton). 

Dentro del codigo, la interfaz ActionListener proporciona un boton para que el usuario 
haga clic para que se “tiren los dados”. Al ver la referencia de Java, notara que la clase 
java.awt. AWTEventMultic aster implementa esta interfaz. 

^Sabe que? jEsto serfa mas facil de comprender si viera el modelo UML! La figura 12.7 
le muestra el diagrama de componentes. Un paquete corresponde al directorio en donde 
se encuentran los archivos, el otro al JDK (Conjunto de herramientas para desarrollo en 
Java). 





Figura 12.7 



El diagrama para el 
juego de dados basado 
en la Web de Rogers 
Cadenhead . 



Crapshoot 



1 \ Die. java 







EuMH 








«E||§b 









Craps, class 



H Craps.java 



| java | 



java. awt. event 


i 

i 


i-- | AWTEventMulticaster 


m 




Termino Nuevo 



Este ejercicio — generar un modelo a partir de un codigo 
existente — se conoce como ingenieria inversa. 



Una pagina Web con controles ActiveX 

ActiveX es el medio de Microsoft para agregar componentes a las aplicaciones. Con 
tantos tipos de componentes ActiveX (controles) disponibles, podra encontrar alguno 
que haga casi todo lo que requiera una aplicacion. Una propiedad de un componente 
ActiveX es su niimero de identification hexadecimal unico de 32 bits, conocido como 
CLSID (identificador de la clase). 

Si sus requerimientos son especiales, podra generar su propio componente ActiveX en 
Visual Basic o Visual C++. Luego podra reutilizarlo de aplicacion en aplicacion. 

En las paginas Web, los componentes ActiveX se encuentran y trabajan con el codigo 
escrito en algun lenguaje para secuencias de comandos como VBScript. En este ejemplo, 
la pagina Web cuenta con un control Timer ActiveX, dos cuadros combinados ActiveX y 
tres botones ActiveX. La pagina Web permite a un usuario establecer los parametros para 









animar el movimiento de una esfera (una imagen .gif) por la pantalla. De un cuadro com- 
binado, el usuario selecciona la cantidad de pixeles por movimiento. Del otro se selec- 
ciona la cantidad de milisegundos entre movimientos. Un boton iniciara el movimiento, 
el otro lo detendra y el tercero restaurara la esfera a su posicion inicial. El cronometro 
movera la esfera cuando pase la cantidad de milisegundos elegida por el usuario. 

Los controles ActiveX se encuentran en un componente separado conocido como 
Disposition (Layout). La pagina HTML y la disposicion se encuentran en el mismo 
directorio. 

La figura 12.8 le muestra el diagrama de componentes para esta pagina. Observe el uso 
del sfmbolo de anotacion para representar al VBScript. Aunque esto no es absolutamente 
necesario, destaca una diferencia entre el lenguaje de secuencias de comandos y los 
componentes compilados ActiveX. 



Figura 12.8 

El diagrama de 
componentes para 
una pagina Web con 
componentes ActiveX. 
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PowerToys 

Si utiliza cualquier version de Win32, ya conocera las horribles flechas pequenas que se 
encuentran en la esquina inferior izquierda de cada icono de acceso directo. Microsoft 
tiene un paquete llamado PowerToys que le permite eliminarlas y hacer varias otras 
cosas con la GUI, mediante una aplicacion llamada TweakUI que es parte del paquete. 

Puede obtener a PowerToys del sitio Web de Microsoft. Es gratis. Cuando lo obtenga 
y descomprima, vera varios archivos con extensiones .dll. Tambien vera un archivo de 






ayuda y otro .CNT. Haga clic en el archivo de ayuda y generara un archivo .GID. Utilice 
la caracteristica Buscar y creara un archivo .FTS. 

La figura 12.9 le muestra un diagrama de componentes que modela a TweakUI en el 
paquete PowerToys, mismo que muestra las dependencias entre los diversos tipos de 
componentes. 



Figura 12.9 
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Diagramas de componentes en el panorama 

Ya casi tiene todo su panorama. La figura 12.10 incluye el diagrama de componentes, 
que se enfoca en una arquitectura de software del sistema. En la siguiente hora, vera 
como modelar la arquitectura de hardware. 











Figura 12.10 

Su panorama del 
UML ahora incluye 
al diagrama de 
componentes. 
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Resumen 

El diagrama de componentes UML es un conglomerado de figuras de los diagramas que 
ya ha visto. En lugar de representar una entidad conceptual como una clase o estado, un 
diagrama de componentes representa a un elemento real: un componente de software. 
Estos componentes se encuentran en las computadoras, no en la mente del analista. 

Un componente puede accederse a traves de su interfaz, una coleccion de operaciones. La 
relacion entre un componente y su interfaz se llama realizacion . Un componente puede 
acceder los servicios de otro. Cuando se hace, utiliza una interfaz de importacion . El com- 
ponente que realiza la interfaz con tales servicios proporciona una interfaz de exportacion. 

La representacion de un componente es un rectangulo con otros dos rectangulos peque- 
nos sobrepuestos en su lado izquierdo. Puede representar una interfaz de dos formas: la 
primera es un rectangulo que contiene information de la interfaz y se conecta con el 
componente mediante una linea discontinua con una punta de flecha representada por 
triangulo sin relleno. La otra es un pequeno circulo conectado al componente con una 
linea continua. Ambos tipos de conexion pretenden mostrar una relacion de realizacion. 







Preguntas y respuestas 

P En un diagrams de componentes, £cual sera la regia de oro para usar simbolos 
que no representen a componentes? 

R Esto lo hara cuando desee indicar algo que sea ciertamente distinto de un compo- 
nente compilado. No es necesario, pero podrfa ayudar a tener otro punto de vista. 
Podrfa utilizar el sfmbolo de la anotacion para representar archivos de encabezado, 
dll, o archivos de secuencias de comandos. Otra posibilidad es la de utilizar el sim- 
bolo regular del componente con un estereotipo que indique el tipo de archivo. 

P Ha utilizado a VBScript como un componente de la pagina Web. El codigo 
de VBScript consta de varios procedimientos. <,No podria modelar cada uno 
como componente? 

R Si, podria. No obstante, podria desordenar su modelo si depurara al VBScript (o 
JavaScript) hasta tal nivel, asf que podria, mejor, agregar una nota que abunde al 
respecto. 



Taller 

En este taller reforzara su conocimiento respecto a los componentes y como modelarlos. 

Uno de los ejercicios trata de los conceptos de una pagina Web, el otro de DLL. El 

Apendice A, “Respuestas a los cuestionarios”, sera el componente del libro que contenga 

las respuestas. 

Cuestionario 

1 . ^Cuales son los tres tipos de componentes? 

2. ^Como llamaria a la relacion entre un componente y su interfaz? 

3. ^Cuales son las dos formas de representar a esta relacion? 

4. ^Que es una interfaz de exportacion? ^Que es interfaz de importation? 

Ejercicios 

1. Adentremonos en la ingenieria inversa para modelar una pagina Web. Visite 
http://www.pearson.com.mx, la pagina Web de Pearson Education (la empresa que 
amablemente publico el libro que ahora lee). Utilice el menu Ver de su explorador 
para seleccionar la option que le deje a la vista el codigo fuente. No encontrara 
ningun componente ActiveX o applet de Java, pero vera diversos archivos .gif y 
cierto codigo en JavaScript. No incluya todos los archivos .gif en su modelo, solo 
algunos para reafirmar su comprension. Vaya al principio del codigo y vera una 
referencia a una hoja de estilo. La referenda se encuentra en un elemento LINK 
de HTML. Este es un archivo por separado que contiene la information de estilo 
para la pagina Web. Asegurese de incluirla en su modelo. 



2. En el diagrama de colaboraciones del caso de uso “Crear propuesta”, el consultor 
busca en el area central de almacenamiento una propuesta adecuada para volverla 
a utilizar. Imagine a “buscar” como un mensaje enviado para buscar en una secuen- 
cia de archivos, y utilice las tecnicas de modelado de la section “Algunos conceptos 
mas” para cambiar el diagrama de colaboraciones en la figura 10.6. 
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Diagramas 
de distribution 

Hasta ahora nos hemos concentrado en el entorno conceptual, aunque en la 
hora anterior vimos los modelos de la arquitectura de software. Es momento 
de concentramos en el hardware. Como podra ver, hemos trascendido desde 
los elementos (como las clases) que se encuentran en los analisis, hasta los 
componentes en los equipos de computo y al hardware existente. 

Claro esta que el hardware es un tema primordial en un si sterna de varios 
componentes. En el mundo actual de la computation, un sistema podrfa 
abarcar diversos tipos de plataformas en ubicaciones dispersas. Un diseno 
solido de distribucion de hardware es basico para el diseno del sistema. El 
UML le da los simbolos para crear una imagen clara de la forma en que 
debera lucir el hardware final. 

En esta hora se trataran los siguientes temas: 

• Que es un diagrama de distribucion 

• Aplicacion de los diagramas de distribucion 

• Los diagramas de distribucion en el panorama del UML 



Que es un diagrama de distribution 



Termino Nuevo 



El elemento primordial del hardware es un nodo , que es un nombre generico 
para todo tipo de recurso de computo. Es posible usar dos tipos de nodos: un 
procesador, el cual puede ejecutar un componente, y un dispositivo que no lo ejecuta. 
Normalmente, un dispositivo (como impresora o monitor) tiene contacto de alguna forma 
con el mundo exterior. 



En el UML, un cubo representa a un nodo. Debera asignar un nombre para el nodo, y 
podra utilizar un estereotipo para indicar el tipo de recurso que sea. La figura 13.1 le 
muestra un nodo. 



Figura 13.1 
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El nombre es una cadena de texto. Si el nodo es parte de un paquete, su nombre puede 
contener tambien el del paquete. Puede dividir al cubo en compartimientos que agreguen 
informacion (como componentes colocados en el nodo), como en la figura 13.2. 



Figura 13.2 
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Otra forma de indicar los componentes distribuidos es la de mostrarlos en relaciones de 
dependencia con un nodo (vea la figura 13.3). 

Figura 13.3 
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Una linea que asocie a dos cubos representara una conexion entre ellos. Podra utilizar un 
estereotipo para dar information respecto a la conexion. La figura 13.4 proporciona 
ejemplos de conexiones entre nodos. 




Figura 13.4 

Representation 
de conexiones 
entre nodos . 




Aunque la conexion es el tipo comun de asociacion entre dos nodos, es posible utilizar 
otros (como la agregacion o la dependencia). Podra representarlas de las formas ya 
conocidas. 

Aplicacion de los diagramas de distribucion 

Un buen lugar para empezar es con un equipo de computo domestico, por lo que el 
primer ejemplo es un diagrama de distribucion del sistema que utilice para escribir este 
libro. 







No obstante, como lo dije, los sistemas actuales de varios procesadores conectan nodos 
que podn'an encontrarse lejanos entre si. Para visualizar completamente este problema, 
necesitara tambien ver los ejemplos de los diagramas de distribucion aplicados a las 
redes. Incluire ejemplos que podran servirle para adaptarlos a su propio entomo. Cada 
ejemplo incluye restricciones que reflejan las reglas de la red particular. 

Un equipo domestico 

Para modelar mi equipo de computo, he incluido al procesador y los dispositivos, a la vez 
de que he modelado mi conexion telefonica con mi proveedor de servicios de Internet y 
su conexion. La nube que representa la Internet no es parte de la simbologla del UML, 
pero es util para clarificar el modelo. La figura 13.5 presenta el diagrama de distribucion 



Figura 13.5 

El diagrama de 
distribucion de mi 
equipo de computo. 




Una red token-ring 

En una red token-ring, las computadoras equipadas con una NIC (tarjeta de interfaz de red) 
se conectan a una MSAU (unidad central de acceso a multiestaciones). Se conectan varias 
MSAU en una serie que podrfa parecer un anillo (por ello la parte “ring” del nombre). El 
anillo de MSAU se combina para fungir como un policfa de transito, mediante una serial 









conocida como token que permite a cada equipo de computo saber cuando puede transmi- 
tir informacion. Asi es, el token va de equipo en equipo hasta que uno de ellos contenga 
informacion por enviar. En realidad, el token se mueve por el anillo de MSAU. 

Cuando se obtiene el token, solo esa informacion del equipo puede ir por la red. Una vez 
que se envia, la informacion viaja hasta su destino. Cuando llega, se devuelve un acuse 
de recibo al equipo que la envio. 

En este ejemplo, que se aprecia en la figura 13.6, he modelado una red que consta de tres 
MSAU y sus respectivos equipos. 



Figura 13.6 

El diagrama de dis- 
tribution de una red 
token- ring que con- 
sta de tres MSAU. 




ARCnet 

Como en una red token-ring, una red ARCnet (Red de Computo de Recursos Adjuntos) 
implica pasar un token o serial de un equipo a otro. La diferencia es que en ARCnet cada 
equipo tiene asignado un ntimero. El orden numerico determina cual equipo obtendra al 
token. Cada equipo se conecta a un concentrador o hub que podra ser activo (ampliflcara 
la informacion que llega antes de transmitirla) o pasivo (transmitira la informacion sin 
amplificarla). 













A diferencia de los MSAU en una red token-ring, los concentradores ARCnet no mueven 
el token en un anillo. Los equipos se lo pasan entre si. 

La figura 13.7 modela una red ARCnet con un concentrador pasivo, uno activo y varios 
equipos. 



Figura 13.7 

Un diagrama de 
distribution de una 
red ARCnet . 




Thin ethernet 

La red thin ethernet es un tipo muy popular. Los equipos se conectan a un cable 
de red mediante dispositivos conocidos como conectores T. Un segmento de red 
puede unirse a otro mediante un repetidor , un dispositivo que amplifica una serial antes 
de transmitirla. Tambien pueden hacerse conexiones de tipo RJ-45, aunque, en este caso, 
nos concentraremos tan solo en la conexion T. 

La figura 13.8 modela una red thin ethernet. 
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Figura 13.8 
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Red inalambrica Ricochet de Metricom 

Metricom, Inc, empresa localizada en Los Gatos, CA, cuenta con una solucion inalambri- 
ca por modem para obtener acceso movil a Internet. Su modem inalambrico se conecta al 
puerto serial de un equipo de computo y se comunica con su red Ricochet. 

La red Ricochet consta de transmisores y receptores de radio, cuyo tamaho es de una 
caja de zapatos. Tales radios de microceldilla se montan en la parte superior de los postes 
de luz a distancias de 400 a 800 metros, en un patron de tablero de ajedrez. Cada radio de 
microceldilla obtiene una pequena cantidad de energla de su poste de luz si se equipa con 
un adaptador especial. 




















Los radios de microceldillas difunden senales a Puntos de acceso cableados que llevan la 
informacion a un NIF (dispositivo de interconexion a la red). El NIF consta de un servi- 
dor de nombres (una base de datos que valida las conexiones), un enrutador (dispositivo 
que enlaza a las redes entre si), y una puerta de enlace (un dispositivo que traduce la 
informacion de un protocolo de comunicaciones a otro). La informacion se lleva del NIF 
a la Internet. 

La figura 13.9 muestra un diagrama de distribucion para esta red. 



Figura 13.9 

Red inalambrica 
Ricochet de 
Metricom. 




Los diagramas de distribucion 
en el panorama 

Ha llegado al final del conjunto de diagramas. El panorama incluye al diagrama de dis- 
tribucion, y ha quedado finalizado. 









Figura 13,10 

Su panorama del 
UML incluye al dia- 
grama de distribu- 
tion y esta completo. 
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Resumen 

El diagrama de distribucion del UML ilustra la forma en que luce un sistema fisicamente 
cuando sea conjugado. Un sistema consta de nodos, donde cada nodo se representa por 
un cubo. Una linea asocia a dos cubos y simboliza una conexion entre ellos. Los tipos de 
nodos son procesador (que puede ejecutar un componente) y dispositivo (que no lo puede 
hacer). Los dispositivos por lo general interactuan con el mundo. 

Como puede imaginar, los diagramas de distribucion son utiles para modelar redes. Los 
modelos presentados en esta hora incluyeron a redes token-ring, ARCnet, thin ethemet y 
la red inalambrica Ricochet. 










Preguntas y respuestas 

P Usted utilizo una nube para representar a la Internet, y dijo que no era parte 
de la simbologia del UML. ^Un modelador puede utilizar simbolos que no 
estan en la simbologia? 

R Asi es. De hacerlo, no habra policfa UML que lo lleve a prision. La idea es utilizar 
el UML para expresar una vision. En ninguna parte esto es tan util como en los 
diagramas de distribucion. Si tiene una imagen que pueda mostrar claramente los 
equipos de escritorio, portables, servidores y otros procesadores (o dispositivos), 
podra utilizarlos en sus diagramas. Claro que estara creando un estereotipo grafico. 
(Por cierto que el simbolo de la nube es una interesante nota al margen por aprender 
en el UML. Uno de los creadores del UML, Grady Booch, solia representar objetos 
como nubes en la simbologia de su esquema de modelado antes de que se convir- 
tiera en parte del equipo del UML.) 

P Suponga que cuenta con una gran cantidad de figuras para representar a cier- 
tos objetos y no a otros. ^Se pueden mezclar con los simbolos del UML? 

R Claro que puede. El objeto es dibujar diagramas para clarificar una vision, no para 
(perdon por el juego de palabras) nublarla. 



Taller 

Ahora que ha finalizado con todo el conjunto de diagramas del UML, pruebe su conoci- 
miento respecto a la forma de representar hardware. Las respuestas se destacan en el 
apendice A, “Respuestas a los cuestionarios”. 

Cuestionario 

1 . ^Como representa a un nodo en un diagrama de distribucion? 

2. ^,Que tipo de informacion puede aparecer en un nodo? 

3. ^Cuales son los dos tipos de nodos? 

4. <rDe que forma funciona una red token-ring? 

Ejercicios 

1. Imagine a su equipo de computo domestico como un conjunto de nodos. Dibuje un 
diagrama de distribucion que incluya a su gabinete, monitor, impresora y cualquier 
otro periferico. Incluya cualquier estereotipo necesario y compartimientos para 
clarificar la informacion (posiblemente resultara en un modelo algo diferente al de 
mi equipo). 

2. Es posible conectar una red a otra. Una forma de hacerlo es conectar a cada red 
con un enrutador y a cada uno de ellos con un (posiblemente muy grande) circuito 
de LAN a LAN. Dibuje un diagrama de distribucion de una pequena red token-ring 
que se conecte a una pequena red thin ethemet. 
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Nociones de los 
fundamentos del UML 

Ahora que ha visto los diagramas en el UML, ya esta listo para ciertos 
conceptos fundamentales. 

En esta hora se trataran los siguientes temas: 

• Estructura del UML 

• Capa del metamodelado 

• Extension del UML 

• Estereotipos, restricciones y valores etiquetados 

Si este fuera un texto academico en lugar de uno de autoaprendizaje, esta 
hora hubiese aparecido al principio de la parte I, en lugar de estar casi al 
final. Hice esto para darle la oportunidad de conocer las trincheras del UML 
(que es y lo que hace). Asi, ya estara listo para conocer los fundamentos y 
trabajar con ellos. 

Ahora que ha visto los diagramas y sabe como utilizarlos, ^para que podrfa 
servirle esta hora? Si ya comprendio en que se basa el UML, podra exten- 
derlo y adaptarlo cuando empiece a utilizarlo en el mundo real. Como 
cualquier analista de sistemas le dirfa: cada proyecto es diferente. No existe 
ningun texto de referenda, libro o manual que lo pueda preparar para todas 
las situaciones con las que se encontrara. No obstante, el tener una buena 
base de los conceptos fundamentales lo preparara para la mayorfa de los 
sistemas que tenga que modelar. 



Es como aprender un idioma extranjero. La mejor forma de hacerlo es sumergirse en el, 
como lo hizo en las horas 1 a la 13 (y como lo hara en la parte II, “Estudio de un caso”). 
Luego podra empezar a captar las reglas gramaticales y sintacticas dado que estara 
preparado para comprenderlas (jpor desgracia, muchos cursos academicos de idiomas 
proceden en orden opuesto!). 

Estructura del UML 

Su panorama del UML le muestra las categorfas de los diagramas y a estos en cada catego- 
rfa. Como lo dije en la hora 1, “Introduction al UML”, necesitara todos los diagramas, 
ya que le permitiran ver su sistema desde diversos puntos. Debido a que hay varias per- 
sonas a las que les interesa el sistema por distintas razones, debera tener la capacidad de 
comunicar una vision consistente del sistema de diversas formas. 

Aunque su panorama es util como una forma de tener a la mano los elementos del UML, 
no funciona como una definition de este. Los tres amigos estructuraron al UML de una 
manera formal para asegurarse que los elementos que habfan creado pudieran mostrar 
una idea clara de un sistema propuesto, o completamente reestructurado. 

El UML cuenta con una arquitectura de cuatro capas. Tales capas se distinguen por la 
generalidad de los elementos que en ellas residen. 




En la actualidad, la palabra arquitectura nos brinca en el mundo del desarrollo 
de sistemas. Imagine una arquitectura como una forma de resumir un conjunto 
de decisiones respecto a la forma en que se organiza un sistema. 

Tales decisiones se enfocan muy especificamente en los elementos del sistema: 
que son, que hacen, como se comportan, como se relacionan y se combinan. 



En las horas anteriores estuvo operando en las dos capas mas especfficas. Cuando siguio 
un ejemplo o realizo un ejercicio que involucraba instancias especfficas de un dominio 
en particular (como el diagrama de componentes de mi sistema de computo personal), 
se encontraba en la capa mas especffica. Esta capa se llama capa de objetos del usuario, 
donde “usuario” se refiere a quien utiliza el UML (no al que utiliza el sistema en sf). 

Estuvo en la siguiente capa cuando vio las clases, como en el ejemplo donde 
el analista hablo con el entrenador de baloncesto para distinguir las clases 
en el dominio baloncesto. Los primeros estados del analisis tienen que ver con esta capa: 
trabajara con un experto o un cliente para obtener la information de un dominio, y con 
los usuarios potenciales para comprender los casos de uso que tendran que tomarse en 
cuenta al generar el sistema. A esta capa se le denomina capa de modelado. 



Termino Nuevo 




Termino Nuevo 



^En que momento estuvo en una capa menor? A1 principio de cada hora cuando 
aprendio un concepto como el de una elase o un nodo, estaba en la tercera de 
cuatro capas. Esta define al lenguaje para un modelo especifico. Luego de que obtenga 
algo de experiencia, se familiarizara tanto con el UML que esta tercera capa le sera algo 
muy natural. Dado que esta capa define lo que va en un modelo, se conoce como capa de 
metamode lado. 




Puesto que en su panorama se muestran los simbolos de las clases, nodos, com- 
ponentes, casos de uso y cosas asi, tal panorama pertenece a la capa de meta- 
modelado. 



la cuarta capa? Durante su carrera como analista, posiblemente nunca ten- 
dra que tratar con ella. Imagmela como una forma de definir un lenguaje que 
especifique clases, casos de uso, componentes y todos los demas elementos del UML 
con los que trabajara. Esto es mas de la incumbencia de los teoricos que disenan y com- 
paran lenguajes que de los analistas que lo usan. Dado que esta capa define lo que va en 
el metamodelo, se conoce como capa de metametamodelado. 

La figura 14.1 le muestra las cuatro capas. 
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Figura 14.1 

Las cuatro capas 
del UML 



Capa del metamodelado: cercano y personal 

Puesto que la capa de metamodelado es la base de su panorama, examinemosla mas deta- 
lladamente. 






Imagine a esta capa como una formation de tres paquetes: Fundamentos, Elementos de 
comportamiento y Administration de modelos. La figura 14.2 le muestra lo que quiero 
decir. 



Figura 14.2 

Los paquetes en la 
capa de metamodelado 
del UML. 
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Fundamentos 



Como en el caso de cualquier paquete, cada uno de estos grupos relacionan elementos 
entre si. (^Utilizamos al UML para modelar al UML? jPor supuesto!) 

^Cuales son estos elementos? El paquete Fundamentos contiene: 

• Nucleo 

• Elementos auxiliares 

• Tipos de datos 

• Mecanismos de extension 

El paquete de Elementos de comportamiento contiene: 

• Comportamiento en comun 

• Colaboraciones 

• Casos de uso 

• Maquinas de estado 

El paquete de Administration de modelos es, en si, un modelo. Es un diagrama de clases 
que muestra como se relacionan los elementos del UML entre si, como son los paquetes 
o subsistemas. 

El paquete de Fundamentos 

Hagamos una retrospectiva y entremos a otro nivel. Empezare con el paquete de funda- 
mentos, cuyos componentes aparecen en la figura 14.3. 




Figura 14.3 
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Los paquetes del 
propio paquete 
de Fundamentos. 


Elementos auxiliares 


---> 


Nucleo 


- -> 


Mecanismos 
de extension 




El nucleo define lo que necesita para crear un modelo UML. Cada uno de los elementos 
definidos es abstracto (lo que significa que no puede crear instancias de el) o concreto 
(con el que si podra). Entre los elementos abstractos se encuentran ElementoDeModelo , 
ElementoGeneralizable y Clcisificador. Entre los concretos se encuentran Clase , Interfaz, 
Asociacion y Tipo de datos. 




Vera en esta seccion que dire que un paquete "define", "establece" o "da los 
detalles formates de" un elemento (o concepto). Elio significa tres cosas: (1) el 
paquete muestra al elemento dentro de un diagrama de clases (otro ejemplo 
de usar al UML para modelar al UML), (2) el paquete contiene reglas para uti- 
lizar el elemento, y (3) el paquete proporciona informacion respecto al signifi- 
cado del elemento. 

El diagrama de clases se conoce como sintaxis abstracts , las reglas se conocen 
como reglas bien formadas, y al significado se le conoce como semantics. 



He aqui otra forma de ver la distincion entre abstracto y concreto. Nunca tendra nada 
en su modelo a lo que usted llame explicitamente ElementoDeModelo o Clasificador 
(aunque claro, utilizara tipos ElementosDeModelo y Clasificadores todo el tiempo). 

Un clasificador, por ejemplo, es cualquier elemento que describe estructura y compor- 
tamiento. Imagine a un clasificador como una forma resumida de referirse a una clase , 
componente, nodo , actor, interfaz , indication, subsistema, caso de uso o tipo de datos . 
Decir que algo se le aplica a un clasificador es equivalente a decir que se aplica a 
cualquiera de estos otros denominadores. 

En tal caso, ^los elementos concretos se derivan de los abstractos? Asi es. ^Ello signifi- 
cara que hablamos de clases y herencia? Por supuesto, pero dado que estamos en la capa 
de metamodelado, en realidad hablamos de metaclases. Por ello, un “clasificador” es una 
“metaclase”. (^Que tanto sentido podna haber tenido esta frase en la hora 1?) 





Continuemos con los otros paquetes dentro de los fundamentos. Elementos Auxiliares, un 
paquete que redeondea al Nucleo, define la Dependencia, Componentes y Nodos, entre 
otros. El paquete Tipo de Datos, especiffca los tipos de datos que el UML utiliza, incluyen- 
do los tipos primitivos (enteros, cadena y tiempo) y enumeraciones. Una enumeration 
como por ejemplo el Booleano lista los valores posible. El paquete de Mecanismos de 
Extension le especifica como puede extender el UML e incluye algunas extensiones ya 
hechas. Analizaremos de manera mas detallada este paquete mas adelante, en la seccion 
llamada Extension del UML. 

El paquete de los elementos de comportamiento 

Este paquete es la parte del UML que se encarga de modelar el procedimiento de un 
sistema. Los paquetes de que consta aparecen en la figura 14.4. 



Figura 14.4 

Los paquetes que 
conforman al propio 
paquete de Elementos 
de comportamiento . 




El paquete de comportamiento comun proporciona los conceptos de los elementos 
dinamicos, y soporta otros paquetes como son: casos de uso, maquinas de estado y 
colaboraciones. Estos “conceptos” incluyen Serial, Enlace y Punto final de asociacion. 

El paquete de colaboraciones abarca un ambito mas amplio que tan solo los diagramas de 
colaboraciones que utilizo en la hora 10, “Diagramas de colaboraciones”. En este con- 
texto, una “colaboracion” describe la forma en que los clasificadores y sus asociaciones 
trabajan en conjunto para realizar una tarea en particular. Los diagramas de colabora- 
ciones y los de caso de uso son parte de la perspectiva. La idea es que los clasificadores 
conformen al contexto de la colaboracion; las asociaciones conforman a la interaccion. 

No es de extranar que el paquete de casos de uso detalle los conceptos (como a un Actor 
y un CasoDeUso) que en el se encuentran. (Ambos conceptos son clasificadores, como 
lo indique en la seccion anterior.) El objetivo general es tener la posibilidad de describir 
el comportamiento de un sistema sin entrar en detalles. 




Tampoco debe sorprender que el paquete de Maquinas de estado de los detalles formales 
de los conceptos que hay detras de los diagramas de estados y de actividad que ya ha 
utilizado. 

Administration de modelos 

Este paquete define al Modelo , Subsistema y Paquete . La meta de estos elementos es 
agrupar los ElementosDeModelo de todo tipo. 



Extension del UML 

Como ya lo ha visto en las horas anteriores, podra pulir sus diagramas UML mediante 
la adicion de detalles que expliquen mejor su significado. Los estereotipos, restricciones 
y valores etiquetados son herramientas utiles dentro del UML. 

Puede crear una extension sobre la marcha para agregar a su modelo cuestiones e ideas 
importantes de su dominio. Esto fue evidente la hora anterior: las restricciones en algunas 
de las comunicaciones entre nodos revelan las reglas de los diversos tipos de redes. 

El UML incluye varios estereotipos, restricciones y valores etiquetados. Como ya lo 
mencione, son parte del paquete Extensiones el cual, a su vez, se encuentra en el paquete 
Fundamentos de la capa de metamodelado. Cada una de estas extensiones incluidas es 
adecuada para uno (a veces dos) de los elementos del UML. Las siguientes secciones 
trataran a tales extensiones. 

Estereotipos 

El proposito de un estereotipo es extender a un elemento del UML para que sea una 
instancia de una nueva metaclase, y se escribe entre dos pares de parentesis angulares. 
Esto agrega una gran flexibilidad. Lo que significa que usted podra utilizar un elemento 
existente del UML como base para crear sus propios elementos: elementos que capturen 
algun aspecto de su propio sistema o dominio de una forma en que no podnan hacerlo 
los elementos del UML. 

La intention del estereotipo es permitir a la entidad recien creada que embone con los 
demas dentro de una herramienta de modelado. Las herramientas de modelado (como 
Rational Rose, SELECT Enterprise o Visual UML) tienen que almacenar y manejar las 
clases para la generation de codigo y la de informes. El mecanismo del estereotipo les 
permite hacerlo con sus creaciones. 

El UML incluye un extenso conjunto de estereotipos generados. Podra agregar de uno 
en uno o dos elementos. Las siguientes subsecciones organizan a los estereotipos en 
terminos de los elementos con que confluyen. 



Dependencia 

La relacion de dependencia puede tomar la mayor cantidad de estereotipos ya creados. 
Cada uno extiende una relacion de dependencia entre un origen (el elemento del cual 
parte la flecha punteada) y un destino (el elemento al que apunta la flecha). Veamos 
rapidamente a cada dependencia estereotipada. 

Una dependencia de tipo «se convierte en» muestra que el origen y el destino son el 
mismo objeto en distintos momentos. El origen se convierte en el destino con (posible- 
mente) diferentes roles y valores. «llamar» tiene una operacion como origen y otra como 
su destino. En esta dependencia estereotipada, la operacion de origen invoca a la de des- 
tino. Una dependencia «copiar» indica que el destino es una copia exacta del origen. En 
una dependencia «derivar», el origen se deriva del destino. 

^Recuerda el concepto de visibilidad de la hora 5, “Agregacion, composition, interfaces 
y realization”? Si tiene una operacion que sea privada dentro de una clase en particular, 
aun podra hacerla accesible a otra clase. Coloque la otra clase (origen) y la operacion 
(destino) en una dependencia «reunir» o «friend». El origen tendra acceso al destino sin 
importar la visibilidad. 

Una dependencia entre dos casos de uso tambien puede tener un estereotipo. Ya ha utili- 
zado dos de ellos, «extender» y «usar», aunque sustituyo «incluir» por «usar». «extender» 
le indica que los comportamientos del caso de uso de destino se agregan al caso de uso de 
origen. «usar» indica que algunos casos de uso tienen cierto comportamiento en comun, 
y este estereotipo le permite utilizar dicho comportamiento sin tener que repetirlo una y 
otra vez. 

Una dependencia «importar» se establece entre dos paquetes. Este estereotipo agrega el 
contenido del destino al espacio de nombres del origen (el aspecto del paquete que agrupa 
los nombres que lo constituyen). 

El estereotipo «instancia» indica que el origen es una instancia de su destino, que siempre 
sera un clasificador. En una dependencia de «metadestino», tanto el destino como el 
origen son clasificadores, y el destino es la metaclase del origen. 

En un «enviar», el origen es una operacion y el destino es una senal. El estereotipo 
muestra que el origen envia la senal. 

Clasificador 

Los estereotipos extienden a los clasificadores de diversas formas. El estereotipo «meta- 
clase» muestra que el clasificador al que esta adjunto es una metaclase de otra clase. El 
«tipodeautoridad» indica que un clasificador tiene objetos que provienen de un antecesor 
en particular. Tambien puede usar «tipodeautoridad» en una dependencia para mostrar 
que el destino es un tipo de potestad del origen. (Normalmente utilizara este cuando 
modele bases de datos.) 




Los estereotipos «proceso» y «subproceso» tienen que ver con el flujo de control. Ambos 
indican que su clasificador es una clase activa; es decir, sus objetos pueden iniciar la ac- 
tividad de control. Un proceso puede consistir de varios subprocesos (flujos de control), 
y puede ejecutarse al mismo tiempo que otros procesos. Un subproceso puede ejecutarse 
junto con otros subprocesos en el mismo proceso. 

Un clasificador con el estereotipo «utileria» es una coleccion titulada de atributos y ope- 
raciones que no son miembros de tal clasificador: un clasificador que no tiene instancias. 

Finalmente, un clasificador puede tener al abuelo (jcasi literal!) de todos los estereotipos: 
«estereotipo». Este indica que el clasificador funciona como un estereotipo, y le permite 
modelar jerarqufas de estereotipos. 

Clase 

Puede obtener algo mas especifico que con los clasificadores: tambien es posible extender 
a una clase. Un «tipo» es una clase que establece un dominio de objetos junto con atribu- 
tos, operaciones y asociaciones. El «tipo» no contiene metodos (algoritmos ejecutables 
para sus operaciones). 

Una «claseDeImplementacion» es lo contrario de un «tipo». Represen ta la implementation 
de una clase en un lenguaje de programacion. 

Generalization 

Es una relation entre clasificadores, con su propio pequeno conjunto de estereotipos. 
«heredar» significa que las instancias del subtipo no pueden substituirse por instancias 
del supertipo. «subclase» hace lo mismo que en las clases: significa que las instancias de 
la subclase no son sustituibles por instancias de la superclase. «privado» denota una 
herencia exclusiva: oculta los atributos heredados y operaciones de una clase a sus ance- 
stros. 

Paquete 

Los estereotipos de los paquetes son directos. Una «fachada» es un paquete que contiene 
referencias a elementos de otro paquete, y que no contiene elementos propios. Un 
«sistema» es una coleccion de modelos de un sistema. Un «cabo» es un paquete que 
proporciona solo las partes publicas de otro paquete. 

Ademas de los elementos que he dicho, un paquete puede incluir patrones. 

Un patron es un tipo de colaboracion entre los elementos que ha probado su 
efectividad en diversas situaciones. Un «marcoDeTrabajo» es un paquete estereotipado 
que solo contiene patrones. 
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Dado que los paquetes pueden encontrarse dentro de paquetes, sirve de mucho tener un 
estereotipo que indique cual de los paquetes esta en el nivel superior. Tal estereotipo es el 
«paqueteDeNivelSuperior». (;Le dije que los estereotipos de los paquetes son directos!) 

Componente 

Los estereotipos para los componentes son aun mas directos. Puede mostrar que un 
componente es un documento, un ejecutable, un archivo, una tabla de datos o una biblio- 
teca. Los estereotipos respectivos son «documento», «ejecutable», «archivo», «tabla» 
y «biblioteca». 

Algunos otros estereotipos 

En esta subseccion, he conjugado algunos estereotipos utilizados con otros elementos 
del UML. 

Un comentario que aparece en una nota adjunta puede tener un estereotipo «requeri- 
miento», que denota que el comentario establece un requisito para el elemento adjunto 
a la nota. 

Dentro de una clase, una operacion o un metodo pueden crear una instancia o destruirla. 
(Quiza haya visto metodos como constructor y destructor en Java.) Tales caracteristicas 
se indican mediante «crear» y «destruir» respectivamente. 

Las restricciones, que son el mecanismo de extension que ahora tratare, pueden tambien 
funcionar con los estereotipos. En ocasiones usara una restriccion para mostrar las con- 
diciones previas a una operacion; aunque algunas veces mostrara sus condiciones posteri- 
ores. Tales restricciones las estereotipara con «condicionPrevia» o «condicionPosterior». 

En ocasiones adjuntara una restriccion a un conjunto de clasificadores o relaciones, y 
necesitara indicar que las condiciones de la restriccion deberan tener todos los clasifi- 
cadores, relaciones e instancias. Para ello, debera estereotipar la restriccion como 
«invariable». 

Estereotipos graficos 

Algunas veces en su dominio, tal vez tendra que obtener un nuevo simbolo o dos para 
transmitir algo a un cliente. Como lo mencione en la hora anterior, los diagramas de dis- 
tribucion pueden encajar de forma importante en esto. Por lo general, hay disponibles 
figuras de procesadores y dispositivos, y pueden remplazar a los cubos que vio en la 
hora 13, “Diagramas de distribucion”. La figura 14.5 le muestra un ejemplo. Es una version 
estilizada de la figura 13.7, un modelo de una ARCNet. 




Figura 14.5 

Un modelo estilizado 
de una ARCNet. 
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Restricciones 

Las restricciones se encuentran entre Haves. Proporcionan las condiciones para las aso- 
ciaciones, extremos de vinculos, generalizaciones y peticiones (transmisiones de senales 
o llamadas a operaciones). 

La restriccion {o} se aplica a un conjunto de asociaciones, y muestra que solo una aso- 
ciacion podra utilizarse para tal conjunto. Otra restriccion basada en asociaciones, 
{implicito}, indica que una asociacion es conceptual. 

Los extremos de vinculos, que son puntos finales de vinculos entre objetos, pueden con- 
tener cualquier cantidad de restricciones. Cada restriccion indica el porque el objeto en el 
extremo del vinculo es visible, {parametro} muestra que el objeto es un valor necesario 
relativo al vinculo, {propio} le indica que el objeto es el despachador de una petition, 
{global} y {local} indican el ambito del objeto respecto al vinculo, {asociacion} denota 
que el objeto es visible por su coalicion. 




Un conjunto de generalizaciones pueden ser {completo} (todos sus subtipos han sido 
especificados) o {incomplete)} (aun pueden agregarse subtipos). Otro conjunto de gene- 
ralizaciones pueden ser {traslapado} (mas de un subtipo puede funcionar como un tipo 
de instancia) o {desarticulado} (solo un subtipo puede ser un tipo de una instancia, lo 
que es predeterminado en la generalizacion). 

Si una peticion se envia a diversas instancias de destino en un orden no especificado, 
es una {difusion}. Si varias instancias devuelven valores, y la mayona de tales valores 
determinan un solo valor, la restriction sera un {voto}. 

Valores etiquetados 

Un valor etiquetado se escribe entre Haves. Consiste en una etiqueta , un signo = y un 
valor . 

Los valores etiquetados ya elaborados son adecuados para los clasificadores, compo- 
nentes, atributos, instancias y operaciones. Una etiqueta {documentation = }, se aplica 
a cualquier elemento. A la derecha del =, debe colocar una description, explication o 
comentario respecto al elemento al que adjuntb este valor etiquetado. 

Puede adjuntar una {ubicacion = } a un clasificador o componente. Cuando lo adjunta a 
un clasificador, debe proporcionar al componente del cual es parte. Cuando lo hace a un 
componente, debe indicar el nodo donde se encuentra. 

El valor etiquetado {persistencia = } puede ir en un atributo, clasificador o instancia. De- 
nota la permanencia del estado del elemento al que lo ha adjuntado. Los valores posibles 
son permanente (el estado persiste cuando la instancia se destruye) y transitorio (cuando 
la instancia se destruye, tambien lo hace el estado). 

{semantica = } especifica el significado de un clasificador o una operation. {responsa- 
bilidad} es una obligation de un clasificador. 



Resumen 

Esta hora trato los conceptos basicos del UML. El objetivo fue el de darle un 
conocimiento profundo que le permitiran aplicar al UML en situaciones reales que no 
siempre puedan reflejarse en los ejercicios de un libro de texto. Hemos tratado estos con- 
ceptos luego de todos los diagramas porque tenia que comprender los elementos del 
lenguaje antes de profundizar en sus fundamentos. 

El UML consta de cuatro capas: objetos del usuario, modelado, metamodelado y meta- 
metamodelado (que van desde espetificos hasta generales). Cuando analice un sistema, 
tipicamente trabajara en las primeras dos capas. Cuando aprenda los conceptos del UML, 
por lo general se encontrara en la tercera. La cuarta capa esta orientada a los teoricos y 
disenadores del lenguaje, en lugar de los usuarios del lenguaje y analistas de sistemas. 




El UML incluye varias extensiones propias. Cada uno de estos estereotipos, restricciones 
y valores etiquetados se orientan a ser usados por uno o dos de los simbolos del UML. 

Si le hubiera dado todos estos conceptos fundamentales al iniciar en la hora 1 ^los habria 
entendido? 

Preguntas y respuestas 

P Veo que el UML tiene varias reglas. ^Quien las implementa? 

R Como ya dije, la policia UML no le acecha para verificar que su modelo sea pre- 
ciso. No obstante, una herramienta de modelado le podra ayudar a cenirse a las 
reglas. Por ejemplo: Visual UML tiene un archivo de estereotipos que usara de un 
modo sensible al contexto. Cuando intente colocar un estereotipo en un elemento 
en particular, solo le permitira seleccionar de los estereotipos adecuados para tal 
elemento, todos ellos en ingles. Ademas, le permitira agregar estereotipos a su 
archivo de estereotipos. 

P Los valores etiquetados parecen ser esotericos. ^Debo utilizarlos? 

R Si, y con frecuencia. Los valores etiquetados integrados, aunque son utiles, pali- 
decen en comparacion con los que usted definira para si. Puede utilizar un valor 
etiquetado para mantener information relacionada con la administration de un 
importante proyecto en su modelo: como los numeros de version y los autores de 
las clases. Es decir, “estado”, “version” o “autor” podrfan ser sus etiquetas, y usted 
establecera los valores adecuados. 



Taller 

Este taller reafirmara su conocimiento de los fundamentos del UML. Utilice sus procesos 
de reflexion en el cuestionario y localice las respuestas en el Apendice A, “Cuestionario”. 
Esta es una hora teorica, por lo que no he incluido ningun ejercicio. 

Cuestionario 

1 . ^Cuales son las cuatro capas del UML? 

2. ^Que es un clasificador? 

3. ^Porque es importante el poder extender al UML? 

4. ^Cuales son los mecanismos de extension del UML? 



Hora 1 5 



Adaptation del UML en 
un proceso de desarrollo 

Ahora que ha comprendido los diagramas del UML y su estructura, ya casi 
es hora de ponerlo a funcionar. El UML es una herramienta maravillosa, 
pero no la utilizara de manera aislada. El UML tiene la intention de impul- 
sar el desarrollo de software, por ello, es necesario aprender los procesos 
y metodologias de desarrollo como un vehiculo para comprender el uso 
del UML en un contexto. 

En esta hora se trataran los siguientes temas: 

• Por que es importante un proceso de desarrollo 

• Por que no son adecuadas las antiguas metodologias para los sistemas 
de hoy 

• El Proceso de desarrollo GRAPPLE 

• Como incorporar al UML en el proceso 

Su empresa requiere un nuevo sistema de computo. Los nuevos compo- 
nentes de hardware y software daran por resultado una ventaja competitiva, 
misma que usted necesitara. Debe empezar el desarrollo, jy pronto! 



Es usted quien ha tornado la decision de generar al nuevo sistema, ha establecido un 
equipo de desarrollo completo, con un gerente de proyectos, modeladores, analistas, 
programadores e ingenieros de sistemas. Ya todos se truenan los dedos, ansiosos por 
empezar. 

Usted es, en otras palabras, un cliente. ^Cuales productos de trabajo esperara obtener 
del equipo de desarrollo? ^Como querra que el gerente de proyectos le reporte? Al final, 
claro, querra un sistema en funcionamiento; pero antes de ello, necesitara ver indicios 
de que el equipo ha comprendido el problema que usted intenta resolver y su vision para 
hacerlo. Necesitar£ ver el avance de su solution, y necesitara saber cual ha sido su avance 
en diferentes puntos. 

Tales inquietudes son comunes con cualquier cliente y en cualquier proyecto de desarro- 
llo que requiera una considerable cantidad de tiempo, dinero y recursos humanos. 

Metodologi'as: antiguas y recientes 

A usted no le gustarfa que el equipo de desarrollo comenzara a codificar sin mas. Despues 
de todo, ^que serfa lo que codificarfan? El equipo de desarrollo tiene que proceder de 
manera mas estructurada y metodica. La estructura y naturaleza de los pasos en un 
esfuerzo de desarrollo es lo que yo entiendo como metodologfa . 

Antes de comenzar a programar, los desarrolladores tienen que comprender con claridad 
el problema. Esto requiere que alguien analice sus requerimientos. Una vez hecho ese 
analisis, ^se podra iniciar la codificacion? No. Alguien tiene que convertir tal analisis a 
diseno. De esta manera, los codificadores comenzaran a producir el codigo a partir 
del diseno, despues de probar y distribuir el codigo se convertira en un sistema. 

El metodo antiguo 

Esta idea demasiado simplificada del proceso de desarrollo podra darle una idea de que 
las etapas deberan sucederse en lapsos claramente definidos, una despues de otra. De 
hecho, las metodologias de desarrollo iniciales se estructuraban de esa manera. La figura 
15.1 le muestra una forma de pensar cuya influencia trascendio por varios anos. Este es 
el metodo “en cascada”, y establece que el analisis, diseno, codificacion y distribution 
van uno despues de otro como las actividades en un diagrama de actividades: solamente 
cuando se haya completado uno se podra iniciar el otro. 

Esta forma de hacer las cosas tiene algunos puntos inquietantes. Por un lado, tiende a la 
realization de tareas individuales. Si un analista no tiene contacto con un disehador, y 
este a su vez no tiene contacto con un desarrollador, existe la posibilidad de que los tres 
miembros rara vez trabajen juntos para compartir puntos de vista importantes. 




Figura 15.1 

El metodo “en cas - 
cad a ” del desarrollo 
del software. 




Otro problema con este metodo es que reduce el impacto de la comprension obtenida en 
el proyecto. (No se equivoque, la comprension evoluciona durante la vida de un proyecto 
aun despues de que un analisis se haya volcado en un diseno — ). Si el proceso no 
puede retroceder y volver a ver los primeros estados, es posible que las ideas desarro- 
lladas no sean utilizadas. Intentar introducir con calzador nuevos puntos de vista durante 
el desarrollo es, cuando menos, bastante dificil. La revision de un analisis y diseno — y 
la ulterior incorporacion de una idea desarrollada — establece una mayor oportunidad de 
exito. 

El metodo reciente 

En contras te con el metodo de cascada, la modema ingeniena de programas tiende a la 
colaboracion entre las fases del desarrollo. Los analistas y los disenadores, por dar un 
ejemplo, hacen revisiones para desarrollar un solido fundamento para los desarrollado- 
res. Estos, a su vez, interactuan con los analistas y los disenadores para compartirles sus 
puntos de vista, modificar los disenos y fortalecer su codigo. 

La ventaja es que conforme crece la comprension, el equipo incorpora nuevas ideas y 
genera un sistema mas confiable. La des ventaja (en caso de haberla) es que algunas per- 
sonas no son muy participativas y pueden mantenerse al margen. En ocasiones, los ge- 
rentes de proyectos quisieran decide a sus clientes: “Ya se finalizo el analisis y ahora 
continuaremos con el diseno. Luego de unos dos o tres dfas de diseno, empezaremos a 
codificar.” 

Tal mentalidad es peligrosa. Establecer barreras artificiales entre las fases podria dar por 
resultado un sistema que no haga exactamente lo que los clientes desean. 









El metodo antiguo fomenta otro problema: es comun el caso de que los partidarios al 
metodo “en cascada” reparten el tiempo del proyecto en la codification. El verdadero 
efecto de esto es que se quita un tiempo valioso al analisis y diseno. 

Lo que debe hacer un proceso de desarrollo 

En los primeros anos de la programacion de computadoras, una persona podia analizar 
un problema, otorgar una solucion y escribir un programa. En los primeros anos de la 
construction de viviendas (cuando la tierra era plana), una persona podia construir una 
casa, tambien. 

En la actualidad la historia ha cambiado. Para desarrollar las diferentes naturalezas de 
sistemas complejos que demandan los negocios de hoy, es mas necesario el uso de un 
equipo. ( Por que? El conocimiento se ha especializado tanto que una persona no puede 
conocer todas las facetas de un negocio, comprender un problema, disenar una solucion, 
traducirla a un programa, distribuir el programa en el hardware y asegurarse que los 
componentes del hardware funcionen de forma conjunta. 

El equipo tiene que formarse de analistas para comunicarse con el cliente y comprender 
el problema, disenadores para generar una solucion, programadores para codificarla e 
ingenieros de sistemas para distribuirla. Un proceso de desarrollo tiene que tomar en 
cuenta todos los procesos anteriores, utilizarlos adecuadamente y asignar la cantidad 
de tiempo necesaria para cada fase. El proceso tambien debe dar por resultado diversos 
productos del trabajo que den indicios de progreso y conformar una estela de respon- 
sabilidad. 

Finalmente, el proceso debera asegurar que sus fases no sean discontinuas. En lugar de 
ello, debe obtenerse information entre las fases para fomentar la creatividad y aumentar 
la facilidad de innovar. La base serfa: es mas sencillo hacer una modification a un 
proyecto y luego hacerla en la casa, en lugar de modificar la casa mientras construye 
la estructura. 

Al llegar a un proceso, existe la tentacion de generar una serie de fases que podrfan traer 
una gran cantidad de papeleo. Algunas metodologi'as que estan disponibles de forma 
comercial lo hacen, con lo que hacen que los gerentes de proyectos llenen interminables 
formularios. El papeleo se complica por sf mismo. 

Una razon de esto es la idea erronea de que la metodologia de la “unitalla” es posible; 
cada empresa es unica. Una empresa tiene su propia cultura, normatividad, historia y 
personal. La metodologia del desarrollo que pueda aplicarse a un consorcio intemacional 
posiblemente fallara en una pequena empresa y viceversa. Al intentar meter con calzador 
una metodologia en una empresa, se tendra la mala impresion de que un papeleo extremo 
podra ayudar. 




Asf que aqui esta el reto. Un equipo de desarrollo debera: 

• Asegurar que el equipo de desarrollo cuenta con una firme comprension del pro- 
blema que se intenta resolver 

• Dar pie a un equipo que conste de una coleccion de responsabilidades 

• Fomentar la comunicacion entre los miembros del equipo que ostentan tales 
responsabilidades 

• Dar pie a la intercomunicacion entre las fases del proceso de desarrollo 

• Desarrollar productos de trabajo que comuniquen el progreso al cliente, y eliminar 
el papeleo superfluo 

i Ah! Por cierto, serfa una buena idea si el proceso origina un producto terminado en un 
lapso corto. 




Se habra dado cuenta que utilizo las palabras proceso y metodologfa de forma 
indistinta. Aunque es posible encontrar algunas diferencias entre ellas, prefiero 
no discutir los detalles. En mi experiencia, la palabra metodologfa se ha tergiver- 
sado de forma paulatina. Creo que si se mezcla la palabra proceso en el tema f 
se puede eliminar tal tergiversacion. 



GRAPPLE I 

Para enfrentar este reto de varias facetas, le presento GRAPPLE (Gufas para la Ingenierfa 
de Aplicaciones Rapidas)). Las ideas dentro de GRAPPLE no son originales. Son una 
condensation de las ideas de varias otras personas. Los Tres Amigos han creado el 
Proceso Racional Unificado, y antes de ello, cada Amigo tenia su propio proceso; las 
ideas en tales procesos son similares a GRAPPLE. El libro de Steve McComell, Rapid 
Development (Microsoft Press, 1996), contiene varias de las mejores practicas que se 
aplican al... bueno... desarrollo rapido de aplicaciones. 

La primera palabra en las siglas de GRAPPLE, Directivas , es importante: esta no es 
una ferrea metodologfa. En vez de ello, es un conjunto de ideas adaptables y flexibles. 
Imagfnelas como un patron simplificado de un proceso de desarrollo. Lo presento como 
un vehfculo para mostrar al UML dentro de un contexto. Con algunos ajustes, GRAPPLE 
puede aplicarse en diversas organizaciones (aunque, tal vez, no a todas). Da la oportu- 
nidad a un gerente de proyectos, con creatividad, de agregar sus propias ideas respecto a 
lo que funcionara en una organization en particular, y puede sustraer los pasos incluidos 
que no funcionen. 






Antes de adentrarnos en el tema de GRAPPLE, he aqui una pregunta que tal 
vez se formule: "^Por que me esta hablando de esto un libro que, se supone, 
trata del UML?" 

La respuesta es que si no le digo a usted algo respecto al proceso de desarrollo 
y le doy un contexto para utilizar al UML, todo lo que habre hecho es mos- 
trarle como dibujar diagramas. Lo importante de esto es mostrarle como y 
cuando utilizar cada uno de ellos. 

En la parte II, "Estudio de un caso", vera un caso de prueba que aplicara a 
GRAPPLE en el UML 



RAD 3 : la estructura de GRAPPLE 

GRAPPLE consta de cinco segmentos. He utilizado “segmentos” en lugar de “fases” para 
eliminar la idea de que una “fase” debe completarse antes de iniciar la otra. (Resist! la 
tentacion de llamarlos “piezas”. “Cinco piezas faciles “ era demasiado hermoso.) Cada 
segmento, en tumo, consta de diversas acciones . Cada accion trae consigo un producto 
del trabajo , y cada accion es responsabilidad de un jugador. 

En muchos casos, el gerente de proyectos puede combinar los productos de trabajo en un 
informe que presente al cliente. Los productos de trabajo, de hecho, tienen el mismo 
proposito que un avance en papel, sin sumergirse en el papeleo. 




Para adaptar a GRAPPLE, un gerente de proyectos podria agregar acciones a 
cada segmento. Hay otra posibilidad, que es profundizar a un nivel inferior, y 
subdividir a cada accion en subacciones. Aun hay otra posibilidad de reordenar 
las acciones dentro de cada segmento. Las necesidades de organizacion esta- 
bleceran el camino a seguir. 



GRAPPLE se encausa a los sistemas orientados a objetos. Por ello, las acciones dentro 
de cada segmento se orientan a crear productos de trabajo de una naturaleza orientada a 
objetos. 

Los segmentos son: 

1 . Recopilacion de necesidades 

2. Analisis 

3. Diseno 

4. Desarrollo 

5. Distribucion 






Esto nos otorga un acronimo RADDD o RAD 3 . Luego del tercer segmento, el gerente 
de proyectos combina los productos de trabajo en un documento de diseno para darselo 
al cliente y los desarrolladores. Cuando se han completado todos los segmentos RAD 3 , 
todos los productos de trabajo se combinan para conformar un documento que define al 
si sterna. 

Antes de iniciar tales segmentos, debe asumir que el cliente ha generado un caso de 
negocios para el nuevo sistema. Tambien debe asumir que los miembros del equipo 
de desarrollo, particularmente los analistas, han lefdo tanta documentacion relevante 
como sea posible. 

Examinemos cada segmento con mayor atencion, sin perder de vista las partes del UML 
que se ajusten a cada uno. 

Recopilacion de necesidades 

Si intenta asignar una importancia relativa a cada segmento, este es un buen candidato 
para ser el numero uno. Si no comprende lo que desea el cliente, nunca podra generar el 
sistema adecuado. Todos los analisis de casos de uso en el mundo no le ayudaran si no 
comprende las bases del dominio del cliente y el problema que quiera que usted resuelva. 

Descubra los procesos de negocios 

Es una buena idea empezar el proceso de desarrollo mediante la comprension de los pro- 
cesos de negocios del cliente, en especial aquellos que tratara de mejorar con el sistema 
propuesto. Para comprenderlo, un analista entrevistara al cliente o a una persona con el 
conocimiento necesario que sea designada por el cliente, a quien le preguntara los pasos 
relevantes del proceso uno por uno. 

Una consecuencia importante sera que el analista obtendra un vocabulario de trabajo en 
un subconjunto de la terminologfa del cliente. El analista usara este vocabulario cuando 
entreviste al cliente en la siguiente accion. 

El producto del trabajo es un diagrama de actividades o conjunto de ellos que captan los 
pasos y puntos decisivos en el proceso (o procesos) del negocio. 

Realice un analisis del dominio 

Esta accion es como el ejemplo de la platica con el entrenador de baloncesto. Puede 
realizarse durante la misma sesion en la accion anterior. El objetivo es comprender de 
la mejor manera posible el dominio del cliente. Observe que esta accion y la anterior 
tratan de conceptos, no del sistema que va a generar. El analista tiene que acomodarse en 
el mundo del cliente, pues, a fin de cuentas, es el interlocutor entre el cliente y el equipo 
de desarrollo. 




El analista entrevista al cliente con la finalidad de comprender las principals entidades 
en el dominio del cliente. Durante la platica entre el cliente y el analista, otro miembro 
del equipo tomara las notas (de forma optima) en un equipo de computo portatil equi- 
pado con un procesador de textos, y un modelador de objetos generara un diagrama de 
clases de alto nivel. Si puede contar con mas de un miembro del equipo que tome notas, 
por su bien hagalo. 

El modelador de objetos prestara atencion a los sustantivos y empezara a convertir a cada 
uno en una clase. Finalmente, algunos de esos sustantivos se convertiran en atributos. El 
modelador tambien prestara atencion a los verbos, que se convertiran en operaciones de 
las clases. En este punto, una herramienta de modelado computarizada seria muy util. 

El producto del trabajo es un diagrama de clases de alto nivel y un conjunto de minutas. 



^Grabar o no grabar? 

^Deberia grabar en cinta de sonido tales entrevistas o tan solo basarse en las minutas? 
£sta es una pregunta comun. Cuando se graba una entrevista, se tiende a no prestar tan- 
ta atencidn, o a s6lo tomar algunas notas muy obligatorias. (Despues de todo, siempre 
podra recurrir a la cinta). Si decide grabar, le sugiero que ignore a la grabadora y tome 
todas las notas como si la grabadora no existiera. 

La grabacidn en cinta de sonido puede ser muy util cuando se encuentra en proceso de 
entrenamiento de un nuevo modelador de objetos. Un modelador experimentado podr£ 
comparar los diagramas del nuevo mediante la grabacion del debate y verificar su minu- 
ciosidad. 



Identification de los sistemas cooperatives 

El poeta del s. XVII John Donne, escribio: “Nadie es una isla, completo en si mismo”. 

Si el hubiera escrito en la epoca actual, tal texto debio decir “Ninguna persona es una 
masa de tierra rodeada de agua, completa en si misma”. Tambien pudo haber escrito 
“Ningun sistema es una isla...”, y as! por el estilo. 

En cualquier caso Donne estarfa en lo correcto. Normalmente, los sistemas de negocios 
actuales no emergen de la nada, tienen que colaborar con otros. En las primeras instan- 
ces del proceso, el equipo de desarrollo vera exactamente de que sistemas dependera 
el nuevo sistema, y cuales dependeran de el. Un disenador de sistemas se encargara de 
esto, y producira un diagrama de distribution como su producto del trabajo. El diagrama 
muestra a los sistemas como nodos, con llneas de comunicacion entre ellos, componen- 
tes residentes y dependencias entre componentes. 





Descubra las necesidades del sistema 

Descubrir las necesidades es muy importante, ya que en esta accion, el equipo realiza su 
primera sesion de JAD (Desarrollo conjunto de aplicaciones). Habra otras mas en el 
curso del GRAPPLE. 

Una sesion JAD reune a quienes toman las decisiones en la empresa del cliente, a los 
usuarios potenciales y a los miembros del equipo de desarrollo. Debe haber alguien que 
modere la sesion; el trabajo del moderador es obtener una respuesta de quienes toman las 
decisiones y de los usuarios acerca de lo que esperan que haga el sistema. A1 menos de- 
bera haber dos miembros del equipo que tomen notas, y el modelador de objetos debera 
refinar el diagrama de clases que se obtuvo previamente. 

El producto del trabajo es un diagrama de paquetes. Cada paquete representa a un area 
de alto nivel de la funcionalidad del sistema (por ejemplo: “ayuda con el servicio a 
clientes”). Cada paquete agrupa un conjunto de casos de uso (por ejemplo: “obtener 
el historial del cliente” o “tratar con el cliente”). 

La complejidad del sistema sera lo que determine la duracion de la sesion. Casi nunca 
sera menor a medio dfa laboral, y podrfa durar hasta toda una semana laboral. La empresa 
del cliente debe hacer el compromiso de invertir el tiempo que sea necesario. 

^Para que acceder a una sesion JAD para desarrollar los requerimientos del sistema? <;Por 
que no solo entrevistar a cada individuo? Como podra recordar, dije que la ultima parte 
del reto de un proceso de desarrollo es generar un sistema en un corto lapso. Las entre- 
vistas individuals pueden tardar semanas, mucho mas si existen conflictos en los itiner- 
aries de las personas. La espera de entrevistas individuales puede ocupar mucho tiempo 
y, con el, puede irse por tierra la supuesta ventaja competitiva de completar rapidamente 
el sistema. Las entrevistas individuales posiblemente contendrian puntos de vista conflic- 
tivos, y se perderfa tiempo en intentar resolverlos. Agruparlos a todos crea una expecta- 
tiva general, en la que los participates podrfan hacer una simbiosis de sus puntos de 
vista en beneficio de todos. 

Presentar los resultados al cliente 

Cuando el equipo finaliza todas las acciones de Necesidades, el administrador de proyec- 
tos presentara los resultados al cliente. Algunas empresas podiian requerir la aprobacion 
del cliente en este punto, para que pueda proceder el desarrollo. Otras podrfan necesitar 
una estimacion de los costos de acuerdo con los resultados. De esta manera, el producto 
del trabajo podrfa variar de acuerdo con la empresa. 

Analisis 

En este segmento, el equipo profundiza en los resultados del segmento Necesidades y 
aumentara su comprension del problema. De hecho, partes de este segmento empezaran 
durante el segmento de Necesidades, conforme el modelador de objetos empieza a depu- 
rar el diagrama de clases durante la sesion JAD de Necesidades. 




Comprension del uso del sistema 

Esta accion es un analisis de casos de uso de alto nivel. En una sesion JAD con usuarios 
potenciales, el equipo de desarrollo trabaja con los usuarios para descubrir a los actores 
que iniciaran cada caso de uso, y los actores que seran beneficiados. (Recuerde que un 
actor puede ser un sistema o una persona.) Un moderador interviene en la sesion, y dos 
miembros del equipo toman notas. Luego de algunos proyectos, el moderador de esta 
sesion podria convertirse en el analista de casos de uso. 

El equipo tambien intentara desarrollar nuevos casos de uso y casos de uso abstractos. El 
producto del trabajo sera un conjunto de diagramas de casos de uso que muestren a los 
actores y las dependencias estereotipadas (“extender” e “incluir”) entre los casos de uso. 

Hacer realidad los casos de uso 

En esta accion, el equipo de desarrollo continua su trabajo con los usuarios. El objetivo 
es analizar la secuencia de pasos en cada caso de uso. Esta sesion JAD puede ser la 
continuacion de la sesion previa. Cuidado: esta es, por lo general, la sesion JAD mas 
compleja para los usuarios. Tal vez no esten acostumbrados a dividir una operacion en 
los pasos que la conforman y, a su vez, tampoco puedan enumerarlos. El producto del 
trabajo es una descripcion textual de los pasos en cada caso de uso. 

Depurar los diagramas de dases 

Durante las sesiones JAD, el modelador de objeto escuchara todos los debates y conti- 
nuara con su depuracion del diagrama de clases. En este punto, el modelador de objetos 
debera rellenar los nombres de las asociaciones, clases abstractas, multiplicidades, gene- 
ralizaciones y agregaciones. El producto del trabajo es un diagrama de clases depurado. 

Analizar cambios de estado en los objetos 

El modelador de objetos depurara el modelo mediante la presentacion de cambios de 
estado conforme sea necesario. El producto del trabajo es un diagrama de estados. 

Definir la comunicacion entre objetos 

Ahora que el equipo cuenta con un conjunto de diagramas de casos de uso y un diagra- 
ma depurado de clases, se definira la forma en que los objetos se comunican. El mode- 
lador de objetos desarrollara un conjunto de diagramas de secuencias y de colaboraciones 
para delinear la comunicacion. Deberan incluirse los cambios de estado. Estos diagramas 
conforman el producto del trabajo de esta accion. 




Analizar la integration con diagramas de colaboraciones 

A1 tiempo de realizar los pasos anteriores, el disenador del sistema descubre los detalles 
especificos de la integracion con los sistemas cooperativos. ^Que tipo de comunicacion 
esta envuelto? <r,Cual es la arquitectura de red? Si el sistema tendra que utilizar bases de 
datos, un analista de bases de datos determinara la arquitectura (fisica o logica) de ellas. 
Los productos del trabajo son diagramas de distribucion detallados y (de ser necesario) 
modelos de datos. 

Diseno 

En este segmento, el equipo trabajara con los resultados del segmento de Analisis para 
disenar la solution. En el diseno y en el analisis se haran las revisiones pertinentes hasta 
que el diseno se haya completado. De hecho, algunas de las metodologias combinan al 
Analisis y al Diseno en una sola fase. 

Desarrollo y depuracion de los diagramas de objetos 

Los programadores tomaran el diagrama de clases y generaran cualesquier diagramas 
de objetos que sea necesario. Daran vida a los diagramas de objetos mediante el analisis de 
cada operation y el desarrollo de un diagrama de actividades correspondiente. Los dia- 
gramas de actividades fungiran como la base de gran parte del codigo en el segmento de 
desarrollo. Los productos del trabajo seran los diagramas de objetos y los de actividades. 

Desarrollo de diagramas de componentes 

Los programadores seran quienes jueguen un importante papel en esta action. La tarea 
sera visualizar los componentes que resultaran del siguiente segmento y mostrar las 
dependencias entre ellos. Los diagramas de componentes seran el producto del trabajo. 

Planeacion para la distribucion 

Cuando se haya completado el diagrama de componentes, el disenador del sistema 
empezara a planear la distribucion e integracion con sistemas cooperativos. Creara un 
diagrama de distribucion que muestre el lugar donde se encontraran los componentes. 

El producto del trabajo sera un diagrama que sea parte del de distribucion generado con 
anterioridad. 

Diseno y prototipos de la interfaz del usuario 

Esto trae consigo otra sesion JAD con los usuarios. Aunque esto es parte del Diseno, esta 
sesion puede ser la continuation de anteriores sesiones JAD con los usuarios — un indi- 
cio de la interaction entre el Analisis y el Diseno — . 




La interfaz del usuario deberia permitir la consumacion de todos los casos de uso. Para 
ello, un analista de GUI debera trabajar con los usuarios para desarrollar prototipos, en pa- 
pel, de las pantallas que corresponderan a grupos de casos de uso. Los usuarios pegaran 
papeletas removibles que representen los componentes de la pantalla (botones, casillas 
de verificacion, listas desplegables, menus y cosas asi). Cuando los usuarios queden sa- 
tisfechos de la posicion de los componentes, los desarrolladores generaran prototipos de 
las pantallas para que sean aprobados por los usuarios. Los productos del trabajo seran 
capturas de pantalla de los prototipos resultantes. 

Pruebas de diseno 

Los casos de uso permiten el diseno de pruebas del software. El objetivo es evaluar si 
el software hace lo que se supone que deberia (esto es, que hace lo que se especifica en 
los casos de uso). Preferentemente, un desarrollador o especialista de pruebas externo al 
equipo de desarrollo debera utilizar los diagramas de casos de uso para crear secuencias 
de comandos en herramientas automatizadas de pruebas. Tales secuencias de comandos 
conformaran el producto del trabajo. 

Iniciar la documentacion 

Nunca es demasiado pronto para empezar a documentar el sistema para los usuarios fina- 
les y gerentes de sistemas. Los especialistas en la documentacion trabajaran en conjunto 
con los disenadores para empezar a generar un panfleto de la documentacion y llegar a 
una estructura de alto nivel para cada documento. Tal estructura es el producto del trabajo. 

Desarrollo 

De este segmento se encargan los programadores. Con suficiente analisis y diseno, este 
segmento deberia realizarse con rapidez y sin problemas. 

Generacion del codigo 

Con los diagramas de clases, de objetos, de actividades y de componentes a la mano, los 
programadores generaran el codigo del sistema. Tal codigo es el producto del trabajo de 
esta accion. 

Verificacion del codigo 

Los especialistas en pruebas (no los desarrolladores) ejecutaran secuencias de comandos 
de prueba para evaluar si el codigo hace lo que se pretende. Los resultados de las pruebas 
son los productos del trabajo. Esta accion alimenta a la anterior y viceversa, hasta que el 
codigo pase todos los niveles de prueba. 

Generacion de interfaces del usuario, 
conexion con el codigo y prueba 

Esta accion crea las interfaces de usuario ya aprobadas. El especialista en GUI las genera 
y conecta con el codigo. Las pruebas ulteriores aseguran que las interfaces funcionen 
adecuadamente. El sistema en funcionamiento junto con las interfaces de usuario, son el 
producto del trabajo. 




Consumacion de la documentacion 

Durante el segmento de desarrollo, los especialistas en documentacion trabajan en para- 
lelo con los desarrolladores para asegurar la entrega oportuna de toda la documentacion, 
la cual es el producto del trabajo de esta accion. 

Distribution 

Cuando un sistema se ha finalizado, se distribuye en el hardware adecuado y se integra 
con los sistemas cooperativos. No obstante, la primera accion en este segmento puede 
iniciar antes de que el segmento de Desarrollo comience. 

Planeacion para copias de seguridad y recuperacion 

El disenador del sistema creara un plan que incluya los pasos a seguir en caso de que 
el sistema falle. El plan, producto del trabajo de esta accion, establece lo que se debera 
hacer para crear una copia de seguridad del sistema y para recuperarse del error. 

Instalacion del sistema terminado en el hardware adecuado 

El disenador del sistema, con toda la ayuda necesaria de los programadores, distribuye 
el sistema terminado en los equipos de computo adecuados. El producto del trabajo es el 
sistema completamente distribuido. 

Verificacion del sistema instalado 

Finalmente, el equipo de desarrollo verifica el sistema instalado. <,Se ejecuta como se 
esperaba? ^E1 plan de copias de seguridad y recuperacion funciona? Los resultados 
de estas pruebas determinaran si se necesita hacer una depuracion ulterior. Tales resul- 
tados conforman el producto del trabajo de esta accion. 

Celebracion 

Sin mayor explication, el equipo de desarrollo podra inventar los productos del trabajo 
de esta accion. 

Resumen de GRAPPLE 

Si revisa los segmentos y acciones en GRAPPLE, vera que los movimientos van de lo 
general a lo especifico: de lo rustico a lo refinado. Empieza con una asimilacion concep- 
tual del dominio, trasciende a la funcionalidad de alto nivel, profundiza en los casos de 
uso, depura los modelos y disena, desarrolla y distribuye el sistema. 

Tambien noto que hay mas acciones en los segmentos de Analisis y Diseho que en el 
de Desarrollo. Esto es por diseno, valga la redundancia. La idea es utilizar tanto tiempo 
como sea necesario en el analisis y diseno, para que la codificacion se realice sin pro- 
blemas. Podria parecer una herejia, pero en el mundo ideal la codificacion es solo una 
pequena parte del desarrollo de sistemas. Entre mas analice, mas cerca estara del ideal. 




GRAPPLE, como lo dije, es un patron simplificado de un proceso de desarrollo. No me 
centre en los detalles en ciertos puntos importantes, como los niveles de prueba. Tambien 
pase por alto algunas cuestiones basicas: ^Donde y como el equipo alberga los producto del 
trabajo en ejecucion? ^Como trata el equipo el importante punto de la administracion de la 
configuracion? 

No aludi a estos puntos porque se salen del tema del UML. Una respuesta corta para estos 
puntos importantes es cobijarse en la tecnologia. Los productos del trabajo (finalizados o 
en ejecucion) pueden encontrarse en un area de almacenamiento que se encuentre en la 
red de la empresa. Una opcion es contar con una jerarquia de directorios a la que puedan 
acceder los miembros del equipo. Una opcion mas segura es instalar un paquete de alma- 
cenamiento central que lleve un control del cumplimiento e inicio de los productos del 
trabajo, y que solo permita que una persona a la vez verifique una copia modificable de 
un elemento. Este es el fundamento de una solucion para la administracion de la configu- 
racion. La tecnologia de almacenamiento avanza con regularidad, y hay varias opciones. 

La hora siguiente dara inicio a la parte II, el estudio de un caso que aplica tanto al UML 
como a GRAPPLE. 

Resumen 

Una metodologia de desarrollo estructura los segmentos y actividades en un proyecto 
de desarrollo de sistemas. Sin una metodologia habria un caos y los desarrolladores 
no comprendenan el problema que se supone deberfan resolver, asi como los sistemas no 
cumplinan con las necesidades de los usuarios. Las metodologias de antano forzaban a 
una secuencia “en cascada” de analisis, diseno, codificacion y distribucion. 

Este tipo de metodologia secuencial podia fragmentar el desarrollo, de modo que un 
equipo de desarrollo podrfa no aprovechar la mejor asimilacion que se obtiene durante 
la vida de un proyecto. Por lo general, tambien distribuye la mayor parte del tiempo 
en la codificacion, y esto resta una enorme cantidad de tiempo al analisis y diseno. 

Esta hora presentb al GRAPPLE (Directivas para el Rapido Diseno de Aplicaciones), un 
patron para el proceso de desarrollo. GRAPPLE consta de cinco segmentos: Recopila- 
cion de necesidades, Analisis, Diseno, Desarrollo y Distribucion. Cada segmento consta 
de diversas acciones, y cada una de ellas da por resultado un producto del trabajo. Los 
diagramas UML constituyen productos del trabajo para varias de las acciones. 

La parte II aplica a GRAPPLE y el UML al estudio de un caso. 




Preguntas y respuestas 

P ^En algiin momento se podria aplicar el metodo “en cascada”? 

R Si el ambito del sistema propuesto es muy pequeno (claro que es algo subjetivo), 
podria aplicarlo sin problemas. No obstante, en el modemo desarrollo de sistemas 
orientados a objetos, una metodologia que propenda a la interaccion entre los seg- 
mentos de desarrollo podra otorgar un mejor resultado. 

P En la respuesta anterior, menciono el desarrollo de sistemas orientados a obje- 
tos. Suponga que el sistema propuesto no esta orientado a objetos. ^Aun asi se 
aplica? 

R Incluso en los sistemas que no esten orientados a objetos (como en muchos pro- 
yectos basados en grandes computadoras centralizadas) se aplican las ideas que 
ha visto en esta hora. Las sesiones JAD, un analisis y diseno de avanzada y la 
interaccion entre los segmentos de desarrollo inclusive seran muy utiles. Podria 
adaptar a GRAPPLE (por ejemplo: mediante la eliminacion del modelado de 
clases), pero esa es la idea: es un conjunto de directivas flexibles en lugar de ser 
una metodologia que tenga que seguirse a pie juntillas. 



Taller 

Ahora que ya comprendio las metodologias, veriflque, con las siguientes preguntas, 
que tanto ha asimilado. El apendice A, “Respuestas a los cuestionarios”, le dara las 
respuestas. 

Cuestionario 

L <;Cuales son algunas de las inquietudes de un cliente? 

2. ^Que se debe comprender como metodologia de desarrollo? 

3. ^Cual es el metodo “en cascada”? ^Cuales son sus debilidades? 

4. ^Cuales son los segmentos de GRAPPLE? 

5. ^Que es una sesion JAD? 



Parte II 

Estudio de un caso 

Hora 

16 Presentacion del caso por estudiar 

17 Elaboracion de un analisis de dominio 

18 Recopilacion de las necesidades del sistema 

19 Desarrollo de los casos de uso 

20 Orientacion a las interacciones y cambios de 
estado 

21 Diseno del aspecto, sensacion y distribucion 

22 Nocion de los patrones de diseno 



Hora 1 6 

Presentation del caso 
por estudiar 

Ahora que ya cuenta con cierta experiencia del UML y se le ha presentado 
el patron de una metodologia de desarrollo, vera como aplicar el UML en un 
proceso de desarrollo. A partir de aqui daremos inicio a la parte II, el estudio 
de un caso que aplica al UML bajo el contexto del proceso GRAPPLE. 

En esta hora se trataran los siguientes temas: 

• El panorama del caso por estudiar 

• Como descubrir y modelar los procesos del negocio 

• Sugerencias al hacer entrevistas 

La empresa multinacional (y ficticia) LaHudra, Nar y Goniff, S.A., ha hecho 
una encuesta sobre el mundo de los restaurantes y ha llegado a sorprenden- 
tes conclusiones: a la gente le gusta comer fuera, pero no disfrutan algunos 
momentos de esa experiencia. 

“Bueno”, dijo LaHudra, “pude haber predicho los resultados de nuestra 
encuesta. Cuando salgo a comer, me disgusta cuando el mesero toma mi 
orden y se desaparece por una hora. Al ir uno a un restaurante con clase se 
espera un trato diferente”. 



“Cierto”, respondio Nar, “En ocasiones cambio de parecer luego de hacer mi orden y quiero 
decirle al mesero que aguarde. O tengo una pregunta... o algo... y no puedo encontrarlo ” 

Goniff asiente: “Estoy de acuerdo. Pero, con todo, el comer fuera es divertido; me agrada 
cuando alguien me sirve y adem&s, me gusta la idea de que el personal de cocina me pre- 
pare la comida. Los resultados de nuestra encuesta muestran que la mayoria de las per- 
sonas tambien opinan de esa forma.” 

“^No habrfa alguna manera en que podamos mantener la experiencia basica y mejorarla 
de alguna forma?” 

“^Cdmo?”, preguntd Nar. 

“jYo s 6 c6mo!’\ dijo LaHudra. “Con tecnologfa” 

Y asf fue que decidieron que uno de sus equipos de desarrollo de software corporativo 
construyera el restaurante del futuro. 

Aplicacion de GRAPPLE al problema 

Los miembros del equipo de desarrollo se cinen al esquema de GRAPPLE. Saben que la 
mayor parte del tiempo en el proyecto deberan orientarlo al analisis y diseno. De esa 
forma, la codificacidn se generard con rapidez y eficiencia, con lo que aumentar4 la posi- 
bilidad de una instalacidn y distribucidn sin problemas. 

El proyecto debe iniciar con la recopilacion de necesidades, y con la asimilacidn del 
dominio del restaurante. Como podra recordar de la hora anterior, la recopilacidn 
de necesidades consta de las siguientes acciones: 

• Descubrir los procesos del negocio 

• Realizar un andlisis del dominio 

• Identificar los sistemas cooperativos 

• Descubrir los requerimientos del sistema 

• Presentar los resultados al cliente 

En esta hora trataremos la primera action. 

Descubrir los procesos del negocio 

LaHudra, Nar y Goniff lo hacen todo a lo grande. Estin listos para entrar en el mundo de 
los restaurantes y han conformado una Division de Restaurantes LNG. Han contratado a 
varios restauranteros, meseros (camareros), chefs y personal de mantenimiento experi- 
mentados. 

Todo lo que esperan es el apoyo tecnologico para el restaurante del futuro. Luego, 
establecerdn su primer restaurante, fntegro, con todo y la tecnologfa para mejorar el 
placer de comer en un restaurante. 




Los miembros del equipo de desarrollo estan de suerte. Iniciaran con un papel en bianco. 
Todo lo que deberan hacer sera comprender los procesos del negocio y el dominio para 
continuar en esa linea. 

El analisis del proceso del negocio empieza con la entrevista de un analista a un res- 
taurantero. Durante la entrevista, alguien tomard nota en una computadora portatil. A 1 
mismo tiempo, un modelador plasmar£ en una pizarra blanca un diagrama de actividades 
que el analista, quien esta tomando nota y el restaurantero podran ver. 

En las siguientes subsecciones, seguiremos la entrevista en cada proceso del negocio en un 
restaurante. La meta es producir los diagramas de actividades que modelen los procesos. 

Servir a un diente 

“Gracias por atendemos”, dice el analista. 

“Es un placer”, dice el restaurantero. “iQue es exactamente lo que desean saber?” 

“Empecemos con una sencilla transaccidn de negocios. iQu€ sucede cuando un cliente 
entra al restaurante?” 

“Bueno, si el cliente tiene un abrigo o chaqueta, le ayudamos a quitirselo, lo almacena- 
mos en un guardarropa y le damos un boleto para solicitarlo posteriormente. Eso mismo 
hacemos con un sombrero. Luego, nosotros...” 

“Un momento. Suponga que hay una linea de espera. ^Primero se forma, o da su nombre 
al capitan, o...?” 

“No. Intentamos que se sienta tan cdmodo como sea posible al llegar. Luego nos preocu- 
pamos por la linea de espera, en caso de haber alguna” 

“De hecho, si hay una lista de espera, le preguntamos al cliente si hizo alguna reser- 
vation. Si la hizo, intentamos honrarlos de forma oportuna y darles asiento tan pronto 
como sea posible. Si no hay una reservation, deja su nombre y puede ir a nuestro bar 
para tomar algo antes de comer. Claro que no es obligatorio que lo hagan. Pueden tan 
solo sentarse en un area de espera claramente indicada ” 

“Interesante. Aun no se han sentado a comer y ya se han logrado algunos puntos de- 
cisivos.” 

Hagamos una pausa para determinar a ddnde llegamos. El diagrama del proceso del 
negocio ahora luce como en la figura 16 . 1 . 

De vuelta a la entrevista. 

El trabajo del analista es continuar por el proceso del negocio. 




Figura 16.1 

Las fuses iniciales del 
diagrama de activi- 
dades del proceso del 
negocio del restau- 
rante, “Servir a un 
cliente ” 




“Bien. Cuando le llegue el tumo al cliente, o que haya llegado un cliente qye hizo reser- 
vacidn, sera hora de sentarlo, inoT 

“Si, pero ahora que lo pienso no es tan sencillo. La mesa debera estar lista; para ello, 
deberd ser limpiada. Un mozo de piso debe cambiar el mantel usado por el cliente ante- 
rior, y acomodar la mesa. Cuando est£ lista, el capital de meseros lleva al cliente a su 
mesa y luego llama a un mesero ” “^lo llama?” 




Observe lo que hace el analista. El restaurantero ha utilizado un nuevo ter- 
mino (nuevo dentro del contexto de la entrevista), y el analista desea que se 
lo defina. 

El saber cuando y como hacer esto es parte del arte de entrevistar, donde la 
experiencia ser^ el mejor maestro. 



“Sf. No es muy complicado dado que los meseros tienen sus areas asignadas de servicio 
y, por lo general, saben cuando esta lista una mesa. Normalmente circundan su area y 
estan atentos a las expresiones del capitan ” 

“^Luego que ocurre?” 

“Bueno, el mesero llega a la mesa, entrega un menu a cada comensal y les pregunta si 
desean alguna bebida mientras se deciden. Luego llamara a un ‘asistente’, quien colocara 
una charola con pan y mantequilla, y llenard un vaso con agua para cada persona en la 
mesa. Si alguien ha pedido una bebida, el mesero la traera ” 






“Un momento. Dijo ‘el mesero’. ^La persona que sirve siempre es un hombre?” 

“No. Hablo de ‘el mesero’ por habito. Lo siento.” 

“Bien. ^Que hay si utilizamos el termino neutral ‘sirviente’? Tambien vi que el cliente 
tiene un par de oportunidades para pedir una bebida.” 

“Sirviente no es una palabra que usemos en el ambito restaurantero. Sugiero que sigamos 
con ‘mesero’ y que se aplique indistintamente a hombres y mujeres. En cuanto a lo de las 
bebidas, es cierto. Si un cliente esta a la espera de una mesa y paso al bar, puede llevarse 
su bebida a la mesa si no se la ha terminado cuando se le haya asignado una mesa. A 
proposito, siempre nos reservamos el derecho de negar el servicio a quien ha consumido 
demasiado alcohol.” 




El entrevistador no es solo un oyente pasivo luego de hacer una pregunta. 

En este caso, el analista ha conjugado un tema en comun a partir de algunas 
respuestas previas, y ha hecho una pregunta basada en algo que ha salido a 
colacion en algunas ocasiones (la oportunidad de pedir algo de tomar). La 
respuesta contiene un extracto de la I6gica de negocios, una regia que sigue 
el negocio en una situacidn en particular. En este caso, la Idgica de negocios 
se aplica a negar el servicio a un cliente alcoholizado. 



“Es bueno saberlo. Regresemos a la mesa donde los comensales deciden que van a con- 
sumir.” 

“Si. Siempre tenemos algunas sugerencias del dfa que no estan en el menu, y el mesero 
se las propone a los clientes.” 

“^Sabe qu 6 es lo que he visto que pasa? La gente le pide al mesero las recomendaciones, 
y los meseros por lo general parecen ser sinceros: le dicen si un platillo es mejor que 
otro. ^,Es algo que usted alienta a hacer?” 

“Asi es. Ciertamente nuestros meseros comen en el restaurante y tienen sus propias opi- 
niones de lo que les gusta y lo que no. Si a ellos realmente no les gusta un platillo en 
particular, queremos que lo digan al chef antes que a los clientes, aunque no tengo incon- 
veniente que expresen una preferencia. Claro que no queremos que los meseros le digan 
a los comensales que la comida es terrible, pero el expresar una preferencia por un 
platillo no esta mal ” 

“Bien. Vamos a resumir. El cliente o comensal deja sus abrigos, entra al bar, aguarda una 
mesa, se sienta ante ella, posiblemente ordena una bebida, se le sirve pan y agua y mira 
el menu.” 



Se sugiere detenerse y resumir de vez en cuando. Le ayudarS a verificar qu£ 
tanto ha asimilado y le da la oportunidad de utilizar ia terminologia del 
dominio, ademcis de que reconforta al entrevistado saber que usted le ha 
puesto atencion. 







“Asf es. El mesero regresa con una bebida y los clientes la beben mientras ven el menu. 
El mesero les da de cinco a diez minutos para hacer su eleccidn y, luego, regresa. El 
mesero regresa antes si, claro, los comensales hacen su eleccidn antes.” 

“<C6mo saben que deben regresar antes?” 

“Bien, los clientes llaman la atencidn del mesero. Por lo general est£ cerca del £rea de la 
mesa, a menos que haya tenido que ir a la cocina a traer un pedido o necesitara hablar 
con los chefs por alguna razon.” 

“^Area?” 

“Si, a cada mesero se le asigna un &rea que consta de varias mesas. Hay una seccidn 
asignada como &rea de fumadores, y el resto es para quienes no fuman.” 

“^C6mo determina quien atiende un £rea?” 

“Altemamos a los meseros en las diferentes dreas ” 

“Bueno, volvamos al proceso de servir. Los comensales hacen su eleccidn, el mesero 
toma la orden en su comanda y luego...” 

“Y luego notifica al chef. Esto lo hace mediante la trascripcidn de la eleccidn en un for- 
mulario, llamado comanda, que le da al chef.” 

“/,Que hay en la comanda?” 

“La mesa, la election y, muy importante, la hora.” 

“^Por qu6 es tan importante?” 

“Debido a que generalmente la cocina estd (espero) muy ocupada, y el chef tiene que dar 
prioridad a las comandas en el orden en que hayan llegado ” 

“^Eso es complicado?” 

“En realidad, se complica mas de acuerdo con su naturaleza .” 

“^C6mo esta eso?” 

“La mayoria de las comidas incluyen un entremes antes del plato principal. A la mayona 
de la gente le gusta comer el plato fuerte caliente, asi que el chef prepara el entremes, 
muchos de ellos ya estdn preparados, como algunas ensaladas, y el mesero se los lleva al 
cliente. El reto esti en llevar el plato fuerte, caliente, a todos los comensales en la mesa 
al mismo tiempo. Digo ‘reto’ porque las personas de la mesa por lo general se terminan 
el entremes en diferentes momentos. Todo el asunto debe estar coordinado .” 

“Hum. Esto suena a proceso separado. Tomaremos esto en una reunion por separado 
desde el punto de vista del chef.” 





El analista ha tornado una importante decision: sacar del contexto una 
secuencia que posiblemente sea parte de un proceso separado. El reconocer 
en que momento hacerlo se obtiene mediante la experiencia. 

Un buen principio es que, si el entrevistado utiliza palabras como "complejo" 
o "complicado", o responde que "si" cuando le pregunta si algo es compli- 
cado, tal vez estara ante un conjunto de pasos que necesitarSn su propio 
modelo. Deje que el entrevistado hable un poco antes de tomar una 
decision como esta. 



“De acuerdo, es una buena idea.” 

“Estamos en el punto donde el chef preparara el plato fuerte. A propdsito, ^que le parece 
este diagrama?” (Yea la figura 16.2.) 



Figura 16.2 

Las fases intermedias 
del diagrama de 
actividades para el 
proceso del negocio 
“ Servir a un cliente ". 






“Creo que ha comprendido. De cualquier forma, el chef preparara el plato fuerte y 
el mesero lo recogera cuando se de cuenta de que los comensales han terminado con el 
entrem6s; posteriormente, el mesero llevara el plato fuerte a la mesa. Los comensales 
ingerir&n sus alimentos, y el mesero regresara al menos una vez para verificar si todo 
esta bien.” 

“Suponga que a un cliente no le ha satisfecho algo de la comida. ^Que ocurre?” 

“Bueno, hacemos nuestro mejor esfuerzo para que le satisfaga, aun cuando nos cueste 
algo de dinero. Es mejor perder algo de dinero que a un cliente.” 

“Buen concepto.” 

“Gracias. Cuando los comensales terminan con sus alimentos, el mesero regresa y pre- 
gunta si desean un postre. En tal caso, el mesero dard el menu de postres y tomara las 
drdenes. En caso de que no deseen postre, preguntard si desean un cafe. Si es el caso, 
traera cafe y tazas y les servira. Si no desean nada, traera la cuenta. Luego de unos 
instantes, regresara y obtendrd el pago en efectivo o en tarjeta de credito. Luego traer£ 
el cambio o los vouchers, los clientes dejar&n una propina, recoger&n sus abrigos y se 
ir&n.” 

“^Es todo?” 

“No necesariamente. El mesero llamar£ al mozo de piso para limpiar la mesa, la 
preparara y estara lista para los siguientes comensales.” 

“Dado que ello no tiene que ver con el cliente, voy a considerarlo dentro de un proceso 
por separado, aunque sea breve. Quiero hacerle un par de preguntas. La primera ^Como 
sabe el mesero que la gente ha terminado?” 

“El permanece en su drea, y echa una mirada a cada mesa. La experiencia le dicta cudnto 
le toma a los comensales ingerir sus alimentos, de forma que se puede anticipar a ello 
cuando est£ cerca de una mesa. ^Otra pregunta?” 

“Si. Dijo que el mesero podna estar en la cocina para hablar con el chef por alguna 
razdn. ^Cu&l serfa tal razon?” 

“En ocasiones un cliente necesita saber cu£nto tardara la preparacidn de un alimento. En 
tales casos, el cliente llama al mesero, quien le pregunta al chef. Una vez que se informa, 
regresa y le responde al cliente.” 




Los entrevistadores se aseguran de agregar cualquier pregunta restante al 
final. 



“^Sabe? Nunca me habia dado cuenta de todo lo que ocurre para servir a un cliente en un 
restaurante” 





“Es curioso que lo diga. Hasta que me pidio que le describiera los pasos, yo tampoco lo 
habia analizado mucho. Pienso que su diagrama esquematiza todo lo que he dicho, y es 
una imagen que aclara mis propias ideas.” (Yea la figura 16.3.) 



Figura 16.3 

El diagrama de activi- 
dades completo para ei 
proceso del negocio 
del restaurante, 

“ Servir a un cliente 
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Como lo vio en la hora 11, “Diagramas de actividades”, puede convertir un diagrama de 
estos en uno con marcos de responsabilidad. Cuando modele un proceso del negocio, serd 
algo muy util dado que el diagrama con marcos de responsabilidad le muestra la forma en 
que cada uno de los responsables figuran en el proceso. La figura 16.4 es un diagrama con 
marcos de responsabilidad para el proceso del negocio “Servir a un cliente”. 





Figura 16.4 



Un diagrama con mar- 
cos de responsabilidad 
para “Servir a un 
cliente 





Preparacion de platillos 

^Recuerda que separo los procesos del negocio que aparecieron en la entrevista? 
Volvamos a reunir al analista con el restaurantero y exploremos el proceso de la 
“Preparacidn de platillos”. 

“En la platica anterior”, decia el analista, “menciono que muchos platillos incluyen un 
entremes antes del plato fuerte, y que la mayoria de las personas prefenan el plato 
fuerte caliente. Indico el reto de traer el plato fuerte a todos al mismo tiempo y tenerlo 
caliente; y menciono la importancia de la coordination. ^Podria ahondar?” 









“Claro.” dice el restaurantero. “La gente en una mesa casi siempre finaliza sus entreme- 
ses, ensaladas o sopas en momentos distintos. Tenemos que coordinamos para traerles a 
todos los platos fuertes. La coordinacidn se realiza entre el mesero y el chef. El chef 
recibe la comanda del mesero y empieza a preparar los entremeses y el plato fuerte. 
Cuando se han preparado los entremeses, el mesero va a la cocina, los toma y los lleva a 
la mesa.” 

“^Y el mesero sabe que ya se han preparado los entremeses porque...?” 

“Porque va a la cocina de vez en cuando. Es aquf donde se inicia la coordination: el 
chef, luego de dar el entremes al mesero, espera a que este le avise cuando la mayorfa de 
los comensales ya casi ha terminado con sus entremeses para poderle dar el toque final a 
cada plato fuerte. El mesero permanece en su drea designada, y no pierde de vista a la 
mesa. En el momento adecuado, el mesero va a la cocina, le indica al chef que los 
comensales casi estdn listos para el plato fuerte, y el chef termina su preparacion. Un 
chef experto, que cuente con un grupo de asistentes, equilibrara la preparacion de 
platillos para varios comensales a la vez. La meta es tener listo el platillo principal tan 
pronto como todos los comensales esten listos para el.” 

“^Esto siempre ocurre a tiempo?” 

“No, no siempre. Pero con un poco de experiencia y sentido comun esto podrfa ser fre- 
cuente. Lo que a veces ocurre es que un comensal lento en un grupo no estd del todo 
listo cuando llevamos el platillo fuerte, pero es un problema menor ” 

“Ya entiendo. ^Que opina de nuestro diagrama para este proceso?” (Vea la figura 16.5.) 




Figura 16.5 

Un diagrama de 
actividades para 
“Preparation de 
platillos ” 




Como en el caso del proceso del negocio anterior, es adecuado generar un marco de 
responsabilidades, como el de la figura 16 . 6 . 









Figura 16.6 

Un diagrama con 
marcos de responsa- 
bilidades para 
“Preparation de 
alimentos 




Limpieza de la mesa 

“Ahora vayamos a otro proceso por separado, aquel en el que el mozo de piso limpia la 
mesa”, dice el analista. 

“Este tambi£n requiere cierta coordination. El mesero se asegura de que todos se hayan 
ido y, luego, llamard al mozo de piso para que se encargue de la mesa. En una noche aje- 
treada, esto tendrd que hacerse con rapidez. No tenemos tantos mozos de piso como 
meseros, dado que esto es un proceso casual. Los mozos de piso no siempre estan cerca, 
por lo que tal vez el mesero se vena en la necesidad de buscar uno.” 

“Creo comprenderlo con ‘encargarse de la mesa’, pero ^podna ser un poco mas especf- 
fico?” 





“Claro. En los restaurantes que yo manejo, tenemos un mantel para cada servicio. Asi 
que el mozo de piso tiene que quitar el mantel usado, amarrarlo, colocar uno nuevo y un 
nuevo juego de cubiertos en la mesa. Dobla las servilletas y acomoda los cubiertos y 
un plato para cada asiento de la mesa. Luego se lleva el mantel doblado a una habitation 
detras de la cocina. Lo empacamos y lo enviamos al cuarto de lavado al dia siguiente.” 

La figura 16.7 muestra el diagrama de actividades para este proceso. 

Figura 16.7 

Un diagrama de 
actividades para 
“Limpieza de la 
mesa ”. 



Lecciones aprendidas 

Si usted es aspirante a analista, recuerde las lecciones aprendidas en esta entrevista: 

• Se recomienda detenerse y resumir de vez en cuando para verificar su asimilacion, 
practicar con la terminologia y hacer que el entrevistado se sienta cdmodo. 

• Siempre pida que el entrevistado le explique cualquier terminologia que no le sea 
familiar. No se preocupe si ello aparenta falta de conocimiento. La razdn por la que 
est£ aquf es para adquirirlo y aprender la terminologia. Despues de todo, va a tener 
que utilizar el nuevo vocabulario cuando penetre en el an&lisis del dominio. 

• A veces, podra hacer una pregunta basada en un tema que perciba como respuesta 
a preguntas anteriores. Mantenga su mente y ofdos abiertos para hacer preguntas 
como estas. La ldgica de negocios con frecuencia emerge de las respuestas. 






• Tome nota cuando aparezcan las reglas de la logica de negocios. Lleve un registro 
de estas reglas. Podrfan ser utiles posteriormente (usted nunca sabe: algun di'a 
podria generar una herramienta para la automatizacion de decisiones que dependa 
de tales reglas). Claro que debe generarse una registro de esto en la minuta. 

• Si siente que cierta parte del proceso se toma complejo, puede optar por sacar tal 
complicacidn del contexto hacia un proceso del negocio por separado. Podria faci- 
litar el modelado y el modelo resultante sera mas claro que si intenta aglomerarlo 
todo en un solo proceso. 

• Obtenga el punto de vista del entrevistado respecto al diagrama de actividades. 
Haga cualquier modificacion que sugiera. 

Ha aprendido mucho esta hora y ahora ya cuenta con algunas valiosas tecnicas. 

Conforme obtenga experiencia, general sus propias tecnicas. 

En la siguiente hora, comprendera el analisis de dominios. 



Resumen 

Esta hora le presento el escenario para el estudio de un caso que aplicara al UML en un 
proceso de desarrollo. En el escenario, el consorcio ficticio LaHudra, Nar y Goniff, S. A 
decide incorporar la tecnologia del computo en el restaurante del futuro. Como analista, 
su trabajo es comprender el proceso del negocio involucrado, comprender el dominio y 
recopilar las necesidades (acciones presentes en el primer segmento de GRAPPLE). 

La recien creada Division de restaurantes LNG le da acceso a los expertos del dominio 
que necesita para comprender los procesos del negocio. 

El contenido de esta hora se ha orientado al dialogo en una entrevista y la forma en que 
podria fluir. Se han intercalado notas que le serviran de gufa para saber como realizar la 
entrevista. El objetivo fue el de mostrarle como convertir los resultados de la entrevista 
en un modelo UML. 

En la siguiente hora, comprendera lo relacionado al analisis de un dominio. 




Preguntas y respuestas 

P ^Siempre se da el caso en que las acciones de un segmento se realicen en el 
orden en que las listo? 

R No. En ocasiones podrfa ser sensato realizarlas en otro orden. Por ejemplo: tal vez 
quiera descubrir los requerimientos de un sistema antes de identificar a los elemen- 
tos cooperatives. A su vez, tenga en cuenta que algunas de las acciones no siempre 
seran necesarias para ciertos proyectos y que algunas de ellas pueden realizarse al 
mismo tiempo que otras. La “G” en GRAPPLE significa “Guidelines” o 
“Lineamientos”. Elio no se puede interpretar como “[Gulp! Es una obligation 
seguirlo asf’ o “Debo hacerlo exactamente asf\ 

P ^Es necesario contar con un solo entrevistador para enterarse de los procesos 
de negocios de un cliente o un experto? ^Dos funcionarfan mejor que uno? 

R Por lo general se recomienda que sea una sola persona la que hable con el experto, 
para que el entrevistado no se sienta como que encara a la inquisition. Podrfa optar 
por rotar a los entrevistadores en algun momento de una sesion. El segundo entre- 
vistador podrfa haber sido el que tomaba las notas, mismo que altemarfa su papel 
con el primer t ntrevistador. 

P ^Hay alguna consideration especial para las notas de la entrevista? 

R Asegurese que haya indicado la fecha, hora, lugar y participantes al principio. 
Nunca sabra cuando necesitard tal informacidn y no necesitard tenerla de memoria. 
A su vez, dentro de las notas intente capturar tanto como le sea posible. Es como 
un estendgrafo en una corte. Si intenta hacer un boceto conforme avanza, podrfa 
estar pasando por alto algo. 

P £No podrfa omitir algo al intentar tomar nota de todo? 

R jPor supuesto — razon por la cual es mejor contar con dos personas que tomen 
notas — ! Seguramente uno de ellos podrfa haber anotado algo que el otro no. 
Recuerde que las notas que tome seran parte del documento que le dara al cliente. 
Entre mds completas esten las notas, sera mas facil rastrear la evolution de una 
idea. 



Taller 

Para realmente captar todo esto, responda al cuestionario y haga los ejercicios. Las 
respuestas estan en el Apendice A, “Respuestas a los cuestionarios”. 

Cuestionario 

1. ^Cual diagrama del UML es adecuado para modelar un proceso del negocio? 

2. ^C6mo podrfa modificar a este diagrama para mostrar que hace cada quitii? 

3. ^Que debe entenderse por “ldgica de negocios”? 



Ejercicios 

1. Intente aplicar los principios de esta hora a otro dominio. Suponga que LaHudra, 
Nar y Goniff le han contratado para encabezar un equipo de desarrollo que genere 
un sistema para su biblioteca corporativa. Inicie el segmento Recopilacion de nece- 
sidades mediante la asimilacion y modelado de los procesos del negocio involucra- 
do. Para ello, tendra que confiar en su propio conocimiento de las bibliotecas. 

Haga anotaciones de su solution dado que utilizara este ejemplo en los ejercicios 
de las siguientes horas. 

2. Revise las entrevistas de esta hora. ^Que partes de la logica de negocios se hicieron 
evidentes? 




Hora 





Elaboration de un 
analisis de dominio 

Ahora continuaremos con el analisis conceptual en el segmento de recopi- 
lacion de necesidades de GRAPPLE. 

En esta hora se trataran los siguientes temas: 

• An&lisis de la entrevista del proceso del negocio 

• Desarrollo del diagrama de clases inicial 

• Agrupacion de las clases 

• Conformation de asociaciones 

• Agregados y objetos compuestos 

• Llenado de clases las clases 

El primer par de acciones en GRAPPLE se orientan al dominio y no al sis- 
tema. Ni la hora anterior ni esta se orientaran al sistema propuesto. Cier- 
tamente, en lo que hemos visto hasta ahora no se ha propuesto sistema 
alguno. Solo tenemos una asignacion vaga de LaHudra, Nar y Goniff para 
valemos de la tecnologia y mejorar el acto de comer en restaurantes. 



El objetivo de las horas 16 y 17 es comprender el dominio. Lo que significa que tenemos 
que conocer los procesos especfficos que intentamos mejorar y el modo en el que operan 
tales procesos. A1 intentar descubrir los procesos del negocio, hemos empezado a alimen- 
tar el conocimiento del equipo de desarrollo en nuestro escenario. Como resultado, los 
miembros del equipo cuentan con un vocabulario que pueden utilizar para comunicarse 
posteriormente con la Divisidn de Restaurantes de LNG. Esto es de gran importancia 
dado que el equipo cuenta con un fundamento para aumentar y cultivar su conocimiento 
en el transcurso del proyecto. 

Analisis de la entrevista del proceso 
del negocio 

El equipo de desarrollo tendra otras entrevistas con los expertos restauranteros, pero 
antes de ello trabajaran con el contexto de la entrevista del proceso del negocio. El 
objetivo es producir un diagrama de clases inicial. Un modelador de objetos hara este tra- 
bajo con el equipo durante la entrevista o mediante los resultados de ella. En este punto, el 
modelador buscara sustantivos, verbos y construcciones verbales. Algunos de los sus- 
tantivos se convertiran en clases dentro del modelo, y algunos otros en atributos. Los 
verbos y construcciones verbales podrdn convertirse en operaciones o las etiquetas de 
asociaciones. 

Examinemos los resultados de la entrevista de la hora anterior. ^Que sustantivos y verbos 
utilizd el restaurantero? 

He aquf los sustantivos: 

cliente, abrigo, guardarropa, vale de guardarropa, sombrero, linea de espera, lista de 
espera, reservation, nombre, bar, bebida, comida, area de espera, mesa, mozo de piso, 
mantel, capitan de meseros, mesero, servidor, area de servicio, comensal, menu, asis- 
tente, charola, pan, mantequilla, vaso, agua, persona, eleccidn de menu, sugerencia 
del dia, restaurante, chef, platillo, cocina, comanda, area de fumadores, formulario, 
hora, entremes, plato fuerte, postre, menu de postres, cafe, taza, cuenta, efectivo, tar- 
jeta de credito, cambio, voucher, propina, cubierto, servilleta, habitation, cuarto de 
lavado. 

Observe que hemos utilizado cada sustantivo en su forma singular. 

Los verbos y construcciones verbales son: 

tener, ayudar, almacenar, dar, formarse, honrar, sentar, salir, aguardar, surgir, deshacerse, 
establecer, caminar, llamar, rondar, ver, gesticular, mostrar, preguntar, ordenar, decidir, 
traer, ir, obtener, finalizar, reservar, rehusar, relatar, pedir, recomendar, alentar, gustar, 
decir, expresar, mirar, regresar, beber, leer, permitir, seleccionar, atender, obtener un 




pedido, servir, recolectar, dejar, limpiar, alistar, anticipar, hablar, venir, convocar, 
localizar, proveer, preferir, coordinar, recibir, verificar, depender, cuidar, limpiar, asegu- 
rarse, encargarse, buscar, quitar, a tar, doblar, arreglar, empacar, enviar. 

Cuando busquemos los sustantivos y verbos, deberemos procurar incluirlos todos. ^E1 
modelador los incluira a todos en el modelo? No. El sentido comun indicard a cudles 
incluir y a cuales no. Sera de mucha ayuda tener mayor contacto con el restaurantero. 

Desarrollo del diagrama de dases inidal 

Ahora pongamonos en los zapatos del modelador y empecemos a desarrollar el diagrama 
de clases. Es aquf donde el sentido comun entra en juego. Primero eliminaremos algu- 
nos de los sustantivos. 

Recordemos en la entrevista que se intento cambiar “mesero” por “servidor”, pero que 
no dio resultado. Asf que podriamos eliminar uno de estos terminos. Tanto el entrevis- 
tado como el entrevistador decidieron usar “mesero”, asf que eliminaremos a “servidor”. 
“Cliente” y “comensal” son sinonimos, por lo que podremos eliminar otro sustantivo: 
nos quedaremos con “cliente”. “Persona” parece ser demasiado generico, asi que tambien 
lo eliminaremos. 

£ Podriamos eliminar a otros? Algunos sustantivos son mas adecuados para usarse como 
atributos y no como clases. En nuestra lista, “nombre”, “hora” y “reservation” caen en 
tal categorfa. Otro de ellos, “cuarto de lavado”, no es parte ffsica del restaurante, por lo 
que podriamos eliminarlo. 

He aquf el otro lado de la moneda: tambien es posible agregar una o dos clases. Si 
analizamos la entrevista, veremos que el restaurantero hizo referenda a “areas asig- 
nadas” y “rotacion de meseros”. ^Quien hace la “asignacion” y la “rotacion”? Pues un 
“gerente”, que agregaremos a la lista. Tal clase podrfa no haber surgido de la entre- 
vista original, dado que el analista se enfoco al cliente, el mesero, el chef y el mozo 
de piso. 




La adicion de una clase (como lo vera en la adicion de clases abstractas) 
refleja la evolucion del entendimiento conforme avanza el proyecto. 




Luego de filtrar los sinonimos y atributos, asf como agregar una clase, ahora esta sera 
nuestra lista de sustantivos que se convertiran en clases: 

cliente, abrigo, guardarropa, vale de guardarropa, sombrero, linea de espera, lista de 
espera, bar, bebida, comida, area de espera, mesa, mozo de piso, mantel, capitan 
de meseros, area de servicio, menu, asistente, charola, pan, mantequilla, vaso, agua, 
servicio, mesero, election, sugerencia del dia, restaurante, chef, platillo, cocina, 
comanda, area de fumadores, formulario, entremes, plato fuerte, postre, menu de 
postres, cafe, taza, cuenta, efectivo, tarjeta de credito, cambio, voucher, propina, 
cubierto, servilleta, habitation, reservation, gerente. 

Nos serviremos de estos sustantivos para generar el diagrama de clases de la figura 17.1, 
donde pondremos en mayuscula la primera letra de cada nombre de clase. Si tal nombre 
tiene m&s de una palabra, las uniremos y pondremos con mayuscula la primera letra de 
cada palabra. Tambien eliminaremos los acentos. 




Figura 17.1 

El diagrama de clases 
initial para el dominio 
del restaurante. 
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Agrupacion de las dases 

Ahora intentaremos conformar algunos grupos significativos. Uno de los grupos consta 
de personas: cliente, servicio, mozo de piso, capitan de meseros, asistente, chef, mesero 
y gerente. Este grupo podria tener alguna division pues todos, excepto el cliente y el 
servicio, son empleados. Asi que nos quedaremos con los grupos cliente, servicio y 
empleado. 

Otro grupo consta de elementos relacionados con alimentos: bebida, comida, pan, mante- 
quilla, agua, sugerencia del dia, platillo, entremes, plato fuerte, postre y cafe. 

Hay un tercer grupo que consta de utensilios: vaso, cubierto, charola, servilleta y mantel. 

El cuarto grupo contiene elementos de transaccidn: vale de guardarropa, cuenta, efectivo, 
cambio, tarjeta de credito, pagare y propina. 

Existe otro grupo que consta de dreas del restaurante: area de espera, area de fumadores, 
bar, guardarropa, cocina, area de servicio, mesa y habitacidn. “Habitation” se refiere a 
aquella que almacena los manteles (y asumimos que otros elementos) que el restaurante 
enviara a la lavanderfa. Para hacerlo mas descriptivo, llamemoslo “cuarto de lavado”. 

Finalmente, podemos agrupar los formularios del restaurante: menu, menu de postres, 
vale de guardarropa, cuenta y formulario. El ultimo se refiere al que se entrega al chef 
con la orden, por lo que lo llamaremos “comanda”. 

Observe que un par de estos elementos pueden encontrarse en dos grupos (formularios y 
elementos de transaction). Esto, como veremos, es admisible. 

^Ahora que haremos con tales grupos? Cada nombre de grupo puede convertirse en una 
clase abstracta: una que no genera instancias por si misma, pero que funciona como 
una clase principal de clases secundarias. Ast, la clase abstracta AreaDeRestaurante tiene 
las siguientes clases secundarias: Bar, AreaDeServicio, Mesa, AreaDeEspera, 
Guardarropa y Cocina. 

Podemos modificar el diagrama de clases de la figura 17.1 y producir el de la figura 17.2. 




Conformation de asociaciones 

Ahora, crearemos y etiquetaremos asociaciones entre algunas de las clases. Los verbos y 
las construcciones verbales podran ayudamos con las etiquetas, y no debemos limitamos 
solo a las de la entrevista. Las etiquetas que sean mas descriptivas podrian sobreenten- 
derse. 

Una estrategia es la de enfocamos en algunas de las clases, ver como se asocian entre si, 
e ir a otro grupo hasta que hayamos desmadejado al conjunto de clases. Posteriormente, 
generaremos las agregaciones y objetos compuestos. A continuation, incorporaremos los 
verbos y construcciones verbales como operaciones de las clases. 

Asociaciones con el diente 

Empecemos con la clase Cliente. ^Cuales clases se asocian con ella? La Reservacion 
serfa una de ellas, y Mesero otra. Algunas otras serian Menu, Alimento, MenuDePostre, 
Postre, Orden, Cuenta, Propina, Abrigo y Sombrero. La figura 17.3 muestra las asocia- 
ciones. 

En este punto podemos tomar algunas decisiones. ^Es necesario incluir Sombrero y 
Abrigo? Despues de todo, nos enfocamos en servir un alimento. Luego de debatir, 
probablemente concluiiiamos que tales clases podnan quedarse en el modelo, porque 
nuestro interes se centra en todo el proceso de salir a comer. Esto nos hara generar otra 
clase, EncargadoDelGuardarropa, dado que alguien debera guardar el abrigo y el som- 
brero del cliente. 

Vamos a etiquetar las asociaciones con algunas frases que las distingan. He aqui algunas 
de ellas: 

• El Cliente hace una Reservacion 

• El Cliente es atendido por un Mesero 

• El Cliente ingiere un Alimento 

• El Cliente ingiere un Postre 

• El Cliente hace una Orden 

• El Cliente elige de un Menu 

• El Cliente elige de un MenuDePostre 

• El Cliente liquida la Cuenta 

• El Cliente deja una Propina 

• El Cliente da a guardar un Abrigo a un EncargadoDelGuardarropa 

• El Cliente da a guardar un Sombrero a un EncargadoDelGuardarropa 

La figura 17.4 le muestra las asociaciones etiquetadas. 




Figura 17.2 

Las clases abstractas 
dividen al diagrama de 
clases en grupos signi- 
ficativos. 






































Figura 17.3 

Las asociaciones 
iniciales a la clase 
Cliente. 



Figura 17.4 

Las asociaciones 
a la clase Cliente 
rotuladas. 
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Ahora vamos a enfocamos en las multiplicidades. Recuerde que una multiplicidad es parte 
de una asociacion: indica cuantas instancias de la clase B se asocian con una de la clase A. 

En la mayorfa de las frases enumeradas, el Cliente se relaciona con una instancia de otra 
clase. La segunda frase es distinta de las otras. Tiene una voz pasiva (“es atendido por”) 
en lugar de una voz activa de otras (como “liquida” o “deja”). Esto sugiere que algo 
diferente podrfa ocurrir con tal asociacibn. Si la invertimos y examinamos la asociacion 
desde el punto de vista del mesero (“El Mesero sirve a un Cliente”), es evidente que un 
Mesero puede atender a varios clientes. 

Las dos frases finales apuntan a un tipo de asociacion que no habiamos visto antes: 

• El Cliente da a guardar un Abrigo a un EncargadoDelGuardarropa 

• El Cliente da a guardar un Sombrero a un EncargadoDelGuardarropa 
^Cbmo modelarfamos esto? 

A este tipo de asociacion se le conoce como tripartita ; esto quiere decir que hay tres 
clases involucradas. Este tipo de asociacibn la modelarfa mediante la conexibn de 
las clases asociadas con un rombo, y escribirfa el nombre de la asociacion cerca de 61, 
como en la figura 17.5. En una asociacibn tripartita, las multiplicidades indican culntas 
instancias de dos clases estdn involucradas cuando la tercera se mantiene constante. En 
este ejemplo, un Cliente puede dar a guardar m&s de un Abrigo a un 
EncargadoDelGuardarropa. 



Figura 17.5 

Una asociacion 
ternaria. 




En la siguiente subsection, vera otra forma de manejar esto. 




Es poslble contar con mas de tres clases en una asociacion. En nombre de la 
generalizacibn, el UML la trata como asociacibn multiple. 



La figura 17.6 le muestra todas las asociaciones del Cliente etiquetadas, donde se 
incluyen las multiplicidades. 





Figura 17.6 

Inclusion de las multi - 
plicidades en las aso- 
ciaciones de la clase 
Cliente. 




Asociaciones con el Mesero 

Ahora utilicemos la asociacion Cliente-Mesero para generar las asociaciones con el 
Mesero. Una forma de modelar cualquiera de las asociaciones del mesero es tratarlas 
como tripartitas: 

• El Mesero toma una Orden de un Cliente 

• El Mesero lleva una Orden a un Chef 

• El Mesero sirve un Alimento a un Cliente 

• El Mesero sirve un Postre a un Cliente 

• El Mesero trae un Menu a un Cliente 

• El Mesero trae un MenuDePostre a un Cliente 

• El Mesero trae la Cuenta a un Cliente 

• El Mesero recoge el Efectivo de un Cliente 

• El Mesero recoge la TaijetaDeCredito de un Cliente 

Esto, sin duda, desordenara al modelo y lo hara dificil de comprender. Una forma mas 
eficiente es examinar tales asociaciones, utilizar la menor cantidad de etiquetas y adjun- 
tar las clases de asociacion adecuadas. 















El trabajo de un Mesero es, aparentemente, el de traer y llevar cosas. “Recoger” se 
sobreentiende como “llevar” y “servir” como “traer”. Etiquetaremos esta asociacion de la 
clase Mesero como “llevar” y “traer”. Adjuntaremos una clase de asociacion, y en ella 
indicaremos lo que se lleva o se trae. Para ello, le daremos un atributo llamado elemento 
y le asignaremos un tipo numerico. Los valores posibles del atributo son los diversos ele- 
mentos que el Mesero podrfa llevar o traer. 

La figura 17.7 le muestra lo anterior una vez puesto en efecto. 



Figura 17.7 

El uso de clases de 
asociacion en las aso- 
ciaciones del Mesero. 




El Mesero tambien se asocia con un Asistente y un Mozo de piso, como muestra la 
figura 17.8. 



Figura 17.8 

Otras asociaciones 
con el Mesero. 











Asistente 




1...* 


Llama a 


1 




Mesero 










1...* 


Llama a 


1 








Mozo 

DePiso 



Asociaciones con el Chef 

El Chef se asocia con el Asistente, el Mesero y con el Alimento, como en la figura 17.9. 





Figura 17.9 

Asociaciones con el 
Chef. 




Asociaciones con el Mozo de piso 

El Mozo de piso realiza algunas tareas, como se establece en la figura 17.10. 



Figura 17.10 

Asociaciones con ei 
Mozo de piso . 




Asociaciones con el Gerente 

El Gerente es una clase nueva que hemos derivado a partir del analisis del dominio. 
Esta clase se asocia con muchas otras hacia las cuales hemos desarrollado las siguientes 
frases: 

• El Gerente opera el Restaurante 

• El Gerente supervisa a los Empleados 

• El Gerente supervisa la Cocina 

• El Gerente se comunica con el Cliente 

La figura 17.1 1 modela tales asociaciones. 









Figura 17.11 

Asociaciones con el 
Gerente. 




Una digresion 

Algo que podrfa imaginar es que debiera eliminar los sustantivos que son roles en las 
asociaciones y contar solo con una clase generica, como Empleado. En la asociacidn, 
pondrfa el nombre del rol cerca de la lfnea de vida adecuada de la asociacidn. 

En algunos contextos (como un sistema de ndminas), ello funcionarfa bien. En este tal 
vez no. Analice las siguientes asociaciones: 

• El Mesero trae al Cliente 

• El Mesero lleva del Cliente 

• El Mesero trae al Chef 

• El Mesero lleva del Chef 

• El Mesero llama al Mozo de piso 

El diagrama lucirfa como en la figura 17.12. 





Figura 17.12 

Modelado con la clase 
Empleado. 




Como puede advertir, los iconos de clase del diagrama se hacen densos y poco claros, y 
aun no hemos incluido las clases de asociacion. 

En todo lo que se relacione con el modelado, deje que le guie la comprension. 

Formacion de agregados y objetos 
compuestos 

Ya hemos conformado y bautizado clases abstractas y asociaciones, pero hay otra dimen- 
sion organizacional. El siguiente paso es localizar clases que sean componentes de otras. 
En este dominio ello no debera ser diffcil. Por ejemplo, un Alimento consta de un Entre- 
mes, un PlatoFuerte, una Bebida y un Postre. El Entremes y el Postre son opcionales. A 
su vez, los componentes se encuentran en un orden especifico que deseamos conservar 
en nuestro modelo. 

He aquf algunas otras composiciones: 

• Una Orden consta de una o varias EleccionesDeMenu 

• Un Restaurante consta de una Cocina, una o varias AreasDeServicio, un 
AreaDeEspera, un Bar y un CuartoDeLavado 

• Un AreaDeServicio consta de una o varias Mesas 

• Un Servicio consta de uno o varios Clientes 

En cada caso, el componente es miembro exclusivo de un agregado, de modo que la 
figura 17.13 los modela a todos ellos como objetos compuestos. 










Figura 17.13 

Objetos compuestos 
en el dominio 
Restaurante. 




Llenado de las clases 

Las entrevistas y sesiones consecuentes seran muy utiles para dar cuerpo a nuestras 
clases. Tenga en cuenta que a partir de este momento, un modelador de objetos debera 
estar en cada sesion y depurara el modelo al mismo tiempo. Podemos comenzar con la 
depuration mediante la adicion de algunos atributos y operaciones. 

Nuestras clases mas importantes parecen ser las de Cliente, Mesero, Chef, Gerente y 
Asistente. Verifique si hay alguna otra clase importante. 




















El Cliente 

^Cu&les son los atributos obvios para un Cliente? He aqui algunos: 

• nombre 

• horaLlegada 

• orden 

• horaServicio 

iQue hay con las operaciones? Nuestra lista de verbos nos podria servir de guia (aunque 
no nos debera limitar). Algunas operaciones del Cliente son: 

• ingerir() 

• beber() 

• estarFeliz (jbromeaba!) 

• ordenar() 

• pagar() 

La figura 17.14 le muestra la clase Cliente. 



Figura 17.14 | Cliente 

La clase Cliente . nombre 

horaLlegada 

orden 

horaServicio 

ingerir() 

beberQ 

ordenar() 

pagar() 



El Empleado 

El Mesero, Chef, Gerente y Asistente son todas clases secundarias de la clase abstracta 
Empleado. Por ello, asignaremos atributos a Empleado y las clases secundarias los 
heredaran. Algunos de ellos son: 

• nombre 

• domicilio 

• numeroSeguroSocial 

• aniosExperiencia 

• fechaContratacion 

• salario 





Para el asistente, hay cosas que son un poco mas complejas. Primero, necesitaremos 
un atributo llamado trabajaCon dado que un Asistente podrfa ayudar a un Mesero o a un 
Chef. Este atributo sera de tipo numerico. 

Las operaciones seran especfficas para cada clase secundaria. Para el Mesero, tales 
operaciones parecen ser adecuadas y pueden verse en la figura 17.15: 

• llevar() 

• servir() 

• recoger() 

• llamar() 

• verificarEstadoDeLaOrdenO 
Para el Chef: 

• preparar() 

• cocinar() 

• darPrioridadO 

• crearReceta() 

Para el Asistente: 

• preparar() 

• cocinar() 

• servirPanO 

v servirAgua() 

Las operaciones del Gerente serfan: 

• supervisarO 

• operarRestaurante() 

• asignar() 

• rotar() 



Figura 17.15 



Empleado 



La clase Empleado y 
sus clases secundarias. 



nombre 

domicilio 

numeroSeguroSocial 

aniosExperiencia 

fechaContratacion 

salario 




La Cuenta 

La Cuenta es, obviamente, una clase importante pues contiene la information del dinero 
que costo la comida. Sus atributos son: 

• totalAlimentos 

• impuesto 

• total 



Dado que total es la suma de totalAlimentos e impuesto, es una variable derivada. 
Nuestro modelo (vea la figura 17.16) lo refleja. La operation de la Cuenta es 
calcularTotal(totalAlimentos, impuesto). 

Figura 17.16 

La clase Cuenta. 



Cuenta 

totalAlimentos 

impuesto 

/total 

calcularTotal() 



Detalles generates de los modelos 

Hasta este punto ya ha recopilado bastante information. He aqui algunas sugerencias 
para ayudarle a mantenerlo todo organ izado. 



Diccionario del modelo 

Cuando conjugue los resultados de las entrevistas, procesos del negocio y analisis de 
dominio, mantenga un diccionario del modelo. Este es un glosario de terminologia en el 
modelo. Le ayudara a mantener la consistencia y a evitar la ambigiiedad. 










Por ejemplo: en nuestro dominio del restaurante, el termino “menu” es prominente. Este 
termino significa una cosa para un restaurantero y otra para un desarrollador de inter- 
faces graficas. “Servidor”, el termino propuesto pero rechazado, podrfa tener implica- 
ciones similares: mientras el restaurantero podrfa pensar en un “mesero”, un ingeniero de 
sistemas podrfa pensar en otra cosa completamente distinta. Si tiene definiciones con las 
que todos esten de acuerdo, o si esta al menos consciente de que palabras podrfan causar 
una gran confusion, evitara muchos problemas subsecuentes. La mayorfa de las herra- 
mientas de modelado le permiten generar un diccionario conforme cree el modelo. 

Organization del diagrama 

Otra sugerencia tiene que ver con la organization del diagrama. No es recomendable 
tener todos los detalles de su modelo de clases en un enorme diagrama. Necesitara un 
diagrama principal que muestre todas las conexiones, asociaciones y generalizaciones, 
pero sera mejor omitir los atributos y operaciones de el. Podra enfocarse en determinadas 
clases si las coloca en diagramas por separado. Normalmente, las herramientas de mode- 
lado le permiten organizar sus diagramas mediante una vinculacion adecuada entre ellas. 

Lecciones aprendidas 

iQue es lo que hemos aprendido en nuestro analisis de dominio? 

• La entrevista del proceso del negocio otorga las bases para el analisis del dominio 

• Los sustantivos resultantes pueden convertirse en candidatos para clases 

• Hay que eliminar los sustantivos que son atributos, y los que son sinonimos de 
otros sustantivos de la lista, asf como los que representen a clases fuera del ambito 
del dominio 

• No pierda de vista la oportunidad de agregar clases que podrfan no haberse men- 
cionado durante la entrevista del proceso del negocio 

• Valgase de algunos de los verbos o construcciones verbales como etiquetas para las 
asociaciones 

• Agrupe las clases y utilice los nombres de los agrupamientos como clases abstractas 

• Agrupe clases en agregados u objetos compuestos 

• Cambie el nombre de las clases para mayor legibilidad 

• Algunas asociaciones pueden ser tripartitas (esto es, que involucran a tres clases) 

• Valgase del sentido comun para denominar asociaciones y establecer multiplici- 
dades 

En la siguiente bora nos iremos del entomo conceptual a los detalles relacionados con el 
sistema. 



Resumen 

Esta hora continuo con el analisis conceptual que inicio en la hora anterior. La entrevista 
del proceso del negocio da por resultado los fundamentos para el analisis del dominio. 
Los sustantivos, verbos y construcciones verbales de la entrevista son los candidatos para 
el diagrama de clases inicial que definen al dominio Restaurante. El sentido comun le 
indicara cu&les utilizar y cuales eliminar. Es posible que agregue clases conforme haga el 
analisis. 

El modelador de objetos agregara sustancia a este diagrama mediante la derivacion de 
clases abstractas, asociaciones y multiplicidades. La derivacion de agregados u objetos 
compuestos le ayudard a organizar al modelo. Seran necesarias otras entrevistas y 
sesiones para dar cuerpo completamente en el modelo, aunque es posible empezar a 
agregar atributos y operaciones en este punto. 

Preguntas y respuestas 

P ^Como sabre cuales clases eliminar de la lista de clases candidatas? 

R Mediante el sentido comun, elimine los nombres de clases redundantes y este cons- 
ciente de los nombres que sean atributos. Elimine los nombres de las clases que 
esten fuera del dmbito del dominio que est£ analizando. Recuerde que tambi£n 
podra agregar clases. 



Taller 

Este taller verifica la muy importante aptitud para el an&lisis del dominio, requerida para 
la creacidn y desarrollo de un diagrama de clases. Las respuestas se encuentran en el 
Ap6ndice A, “Respuestas a los cuestionarios”. 

Cuestionario 

1. ^De que forma utilizaremos los sustantivos obtenidos en la entrevista con un 
experto? 

2. de que forma utilizaremos los verbos y construcciones verbales? 

3. ^Que es una asociacion “tripartita”? 

4. £C6mo modelaria una asociacion tripartita? 




Ejercicios 

1. Revise las asociaciones tripartitas del cliente con el EncargadoDelGuardarropa. 
Utilice una clase de asociacion para modelarlas de forma eficiente. 

2. Si ha seguido con atencion la entrevista y el analisis del dominio, tal vez habra 
pensado en algunas clases que no aparecieron en ninguna de tales instancias. Una 
de ellas serfa el Cajero. Conforme una asociacion entre el Mesero y el Cajero. 
Utilice una clase de asociacion en caso de ser necesario. Si puede pensar en otras 
clases, incorporelas en el analisis del dominio. 

3. Nuestro objeto compuesto Restaurante incluye solo a clases “fisicas”: areas como 
la Cocina y Bar. Tal vez podrfa decirme que un restaurante tambien incluye a 
gente. Revise el objeto compuesto Restaurante e incluya a los empleados en el 
diagrama. ^A1 incluir a los empleados se convierte al objeto compuesto en un 
agregado? 

4. Adem&s de los atributos y operaciones, apunte en la hora 3, “Uso de la orientacidn 
a objetos”, que podrfa representar la responsabilidad de una clase. En la clase 
Mesero, agregue un panel de responsabilidades y asignele una descripcidn de la 
responsabilidad propia del mesero. 

5. Continue con el dominio Biblioteca de los ejercicios de la hora 16, “Presentacidn 
del caso por estudiar”, y desarrolle un diagrama de clases. 





Hora 





Recopilacion de las 
necesidades del sistema 

Las dos horas anteriores trataron de cuestiones conceptuales respecto al 
dominio. Derivo procesos del negocio y genero diagramas de clases. Ahora 
iremos al sistema. 

En esta hora se trataran los siguientes temas: 

• Como vislumbrar el sistema 

• La sesion Desarrollo conjunto de aplicaciones (JAD) 

• Como organizar las necesidades del sistema 

• El aprovechamiento de los casos de uso 

Los senores LaHudra, Nar y Goniff estan impresionados. Han visto el resul- 
tado de su equipo de desarrollo y saben que el proyecto va en la direccion 
correcta. Todos parecen tener una buena comprension del dominio Restau- 
rante, tanto que los restauranteros de la Division de Restaurantes de LNG 
dicen que los diagramas han aclarado su propio concepto de las operaciones 
de un restaurante. 



Ahora el equipo tencM que trabajar en la parte medular, es decir, en la parte tecnica para 
el restaurante del futuro. Ya cuentan con los procesos del negocio y los diagramas de 
clases. Ya pueden empezar a codificar ^cierto? jNo! Ni siquiera estan cerca de escribir un 
programa. Antes que nada, tienen que desarrollar una vision del sistema. 

La mayoria de los proyectos empiezan con frases como “Generar una base de datos 
con la informacion del cliente y hacerla facil de usar para que los empleados puedan 
utilizarla con un minimo de capacitacion” o “Crear un entomo de ayuda computarizado 
que resuelva los problemas en menos de un minuto”. Aqui, el equipo de desarrollo ha 
comenzado la mision de “usar la tecnologia para construir el restaurante del futuro”. 
Tienen que vislumbrar a este restaurante basado en tecnologia para tener una idea de la 
forma en que el personal del restaurante trabajara en el. Trabajan en un nivel en el que un 
equipo ie desarrollo usualmente no llega, y LaHudra, Nar y Goniff conffan en ellos. 

El equipo utilizara el conocimiento del proceso del negocio y el recien adquirido 
conocimiento del dominio para ver en que lugar la tecnologia podna mejorar la experien- 
ce de comer en un restaurante. Escuchemos una reunion del equipo. Los integrantes 
son un analista, un modelador, un restaurantero, un mesero, un chef y un ingeniero de 
sistemas. Habra un moderador en la reunion. 

Desarrollo de la idea 

Moderador: “A1 analizar nuestros diagramas de procesos del negocio, pienso que 
podemos ver varios lugares donde podrfa ser util la tecnologia basada en computadoras. 
Hare una lista en la pizarra. ^Quien quiere empezar?” 




El moderador distribuye copias de la figura 18.1, el diagrama de procesos 
del negocio para "Servir a un cliente", y la figura 18.2, el de "Preparar un 
platillo". 



Analista: “Si, aparentemente el negocio del restaurante, como casi cualquier otro, 
depende de la transmision de la informacion. Si podemos agilizar tal transmision (algo 
en lo que la tecnologia se especializa) cumpliremos nuestra meta.” 

Restaurantero: “No me queda muy claro. ^Que quieren decir con ‘transmision de la infor- 
mation’? Siempre pense que mi negocio se centraba en el movimiento de alimentos.” 




Ingeniero de sistemas: “Yo le puedo explicar. Cuando el cliente hace una orden, le da 
information al mesero... por cierto, recordemos que mesero es alguien que sirve las 
mesas. Una vez que el mesero tiene la information, se la lleva al chef, con ello esta 
transmitiendo information.” 

Moderador: “^Donde mas se transmite information en el diagrama?” 

Mesero: “Creo que cuando un cliente me pide que le informe como va el avance de su 
orden y yo le pregunto al chef, ello tambien puede traducirse como transmision de infor- 
mation ^no?” 

Analista: “Asf es ” 

Chef: 'Transmision, tecnicismos. No se ofendan, pero yo no me emociono para nada 
cuando un mesero entra y me pregunta cuanto mas tardare en terminar de preparar un 
platillo. Tardara lo que tenga que tardarse y no puedo ser molestado.” 

Moderador: “Bueno, tal vez podrfamos hacer algo por reducir su molestia. ^Ven algunos 
otros puntos de transmision de information?” 




En este caso el moderador intenta suavizar las cosas con el chef para que 
este continue involucrado. 



Restaurantero: ‘YQue tal cuando el mesero hace la sugerencia del dia? cuando 
responde a una pregunta acerca del menu?” 

Moderador: “jPor supuesto!” 

Chef: “En ocasiones yo tambien tengo que dar respuestas. Las personas me envian al 
mesero para pedirme alguna receta en particular. A veces se las envio mediante el mesero 
y, si no hay mucho trabajo, yo mismo voy y hablo con el cliente. A ellos les gusta eso ” 

Mesero: “Pues hay cierta information que no me gusta transmitir. Un cliente hace una 
orden, voy y se la paso al chef, y luego de quince minutos, cuando regreso a la cocina 
por cualquier otra cosa, oigo que ya se acabaron los ingredientes para tal orden. Yo tengo 
que ir con el cliente y sugerirle que ordene alguna otra cosa. Generalmente eso molesta 
mucho al cliente y a mi tambien, debido a que reduce mi propina ” 

Analista: “Tal vez podrfamos agregar esto al proceso del negocio.. .” 

Moderador: “Tal vez. Pienso que, si estan de acuerdo, podrfamos tratarlo en otra 
reunion.” 




Figura 18.1 

Un diagrama de proce- 
sos del negocio para 
“Servir a un cliente 




Figura 18.2 

Un diagrama de proce- 
sos del negocio para 
tl Preparacidn de 
platillos”. 




Recoger el plato fuerte 



Uevar plato fuerte 




El moderador intenta mantener bien enfocada la reunibn. Observe que el 
moderador evita utilizar la enojosa construccion "Sf, pero...". 



Analista: “Si, claro. No seria bueno desviamos del tema ” 

Moderador: “Veamos donde hemos llegado. De acuerdo con la lista que he hecho, la 
transmision de la informacion se realiza cuando 

• El cliente hace una orden 

• El mesero lleva la comanda al chef 

• El cliente pide al mesero el grado de avance de su orden 

• El mesero da la sugerencia del dia 



El mesero responde a una pregunta de algo en el menu 
El chef responde a inquietudes respecto a alguna receta.” 




Es muy adecuado que, en la entrevista del proceso del negocio, el moderador 
haga una pausa para resumir. 



Analista: “S 6 que no esta en ninguno de nuestros diagramas de negocios, pero ^que 
acaso el cliente no tiene preguntas sobre algo en la cuenta? Cuando el mesero le da la 
respuesta, tambien se tiene transmisidn de informacion .” 



Moderador: “Correcto. ^Algo mas de los procesos del negocio?” 

Ingeniero de sistemas: “Creo que si. iQue hay de la famosa coordinacidn entre el mesero y 
el chef? Es decir, ^en que momento saben que debe servirse el plato fuerte una vez que los 
clientes han terminado sus entremeses? Tambien, esto es informacidn que se transmite .” 

Analista: “De acuerdo. La informacion se transmite de distintas formas en este caso ” 

Restaurantero: “Solo nos dio dos diagramas de procesos del negocio y recuerdo que 
creamos otro ” 

Moderador: “Asf es. Aqui esta el de ‘Limpieza de una mesa’” (vea la figura 18.3). 



Figura 18.3 

Un diagrama de pro- 
cesos del negocio 
para “Limpieza de 
una mesa ” 







Analista: “Parece que aquf solo hay un caso de transmision de information , pero apuesto 
que es muy importante: El mesero llama al mozo de piso para hacerle saber que es hora 
de limpiar la mesa.” 

Restaurantero: “Esto es muy importante. No puede sentar a un nuevo grupo de personas 
en la mesa si no esta lista. Si la limpieza no se realiza tan rapido como sea posible, ten- 
dremos muchos clientes hambrientos, y molestos, amontonados en el bar y en el area de 
espera.” 

Modelador: “He ido modificando mis diagramas de clases mientras transcurre la reunion. 
<,Puedo hacer una pregunta? ^Seria bueno que nuestro sistema (como sea que luzca) nos 
permitiera evaluar nuestra eficiencia en conjunto para atender a nuestra clientela?” 

Restaurantero: “jClaro! De esa forma sabrfamos dbnde y como mejorar. [, En que esta 
pensando?” 

Modelador: “En nuestra clase Cliente hay un atributo horaLlegada y otro horaServicio. 
Quisiera agregar un atributo derivado que se llame tiempoEspera, que podria ser la dife- 
rencia entre horaLlegada y horaServicio. <,Que opinan?” 

Restaurantero: “Me parece bien. Asi sabremos que tal estamos en cuestiones de eficiencia.” 

Analista: “As( es. Tendran muchos datos con los que podran jugar, por ejemplo, 
tiempoEspera como una funcion de la hora del dia, o como una funcion de cuantos 
meseros estaban laborando en ese momento o cosas como esas.. .” 

Modelador: “Hay otra posibilidad. i Y si agregamos otro atributo llamado horaSalida, y 
un atributo derivado llamado duracionComida que seria la diferencia entre horaServicio 
y horaSalida?” 

Moderador: “Parece ser una buena sugerencia. La agregare. Alguna otra?” 

Modelador: “Ya que estamos con los atributos de tiempo, /,que tal si agregamos algunos 
atributos de tiempo a las clases Mesero y Chef que indiquen al gerente el tiempo que se 
tardan en realizar el trabajo?” 

Restaurantero: “Huy, no... La idea de supervisar el rendimiento de los empleados no es 
muy agradable para ellos y para mi tampoco. No porque sean perezosos (no lo son), sino 
porque no es agradable sentirse acosado por una especie de capataz. Es mejor que todos 
se sientan a gusto en el trabajo; de esta manera, el restaurante sera mejor y los clientes tam- 
bien se sentiran mas a gusto.” 




Chef: “Si, estoy de acuerdo. Como lo dije, cuando se prepara un platillo se tardard lo que 
tenga que tardarse. No quiero tener un manojo de comandas y tener un capataz que me 
diga que tengo que tardarme cuatro minutos y medio menos en preparar una trucha a la 
almandina.” 

Mesero: “Y yo no quiero oir que me he tardado mucho en llevar el menu de postres cuando 
los clientes hayan terminado con sus alimentos. Hay muchas cosas involucradas .” 

Modelador: “Bien, bien, idea descartada. De hecho, ya que lo mencionan, creo que debo 
quitar ‘supervisar’ como operation de la clase Gerente. Entretanto, he aqui la forma en que 
luce la clase Cliente ahora.” (Vea la figura 18.4.) 



Figura 18.4 

La clase Cliente 
actualizada. 



Cliente 

nombre 

horaLlegada 

orden 

horaServicio 

/tiempoEspera 

horaSalida 

/duracionComida 

ingerlr() 

beber() 

ordenar() 

pagarQ 




Las ideas del modelador muestran que se encuentra modificando constante- 
mente los diagramas de clases. 

El debate entre el modelador, el restaurantero y el mesero dejan entrever 
un punto crucial: es necesario que las personas del negocio participen en el 
desarrollo del sistema. Sin las opiniones tanto del restaurantero como del 
mesero, el proyecto de desarrollo podria haber gastado tiempo y dinero en 
instaurar algunas caracteristicas para la supervision del rendimiento que no 
servirfan a posteriori. Los empleados podri'an haber reaccionado de manera 
negativa, lo que causaria repercusiones en el sistema y, eventual mente, en el 
restaurante. 



Moderador: “Por lo que he escuchado, parece que podemos distinguir dos tipos de agili- 
dad. Uno de ellos involucra la velocidad con que se transmite la information, y la otra 
a la rapidez con que cada empleado realiza una tarea. El sentir del grupo deja entrever 
que la segunda es una molestia, pero la primera no. ^Estoy en lo correcto?” 

(Todos asienten). 

Analista: “Bien, ya que estamos de acuerdo en ello, ^podrfamos ver algunas otras ideas 
respecto a lo que el sistema harfa espetificamente?” 

Moderador: “Claro. ^Alguna idea?” 






Mesero: “Cuando transmito toda esta information, camino mucho en el transcurso de 
una tarde. En ocasiones tengo que trabajar en un area que esta lejos de la cocina. El ca- 
minar tanto se lleva tiempo — sin contar las suelas de mis zapatos — ” 

Analista: “Bien, pues parece que tendremos que hacer algo para eliminar, o al menos 
reducir, el tiempo muerto. Con ello podrfamos agilizar la transmision de la information.” 

Moderador: “^Tiempo muerto?” 

Analista: “Si. Nuestro sistema debe evitar que los meseros caminen de mas. Es obvio que 
tendrdn que ir a la cocina para llevar la orden a los clientes, pero que tal si logramos 
que sea a lo unico que vayan a la cocina? suponga que pudieran ir a ella justo a 
tiempo para traer la orden?” 

Ingeniero de sistemas: “Pues creo que ya nos estamos concentrando en algo importante. 
Se me ocurre que podrfamos establecer una pequena red que conecte a los meseros con 
la cocina, incluso con los mozos de piso. Asi la information se transmitirfa con mucha 
rapidez.” 

Analista: “No quisiera sonar demasiado analitico aqui pero. . . i Una pequena red? Tendran 
que brincar cables para llegar a las terminales. En lugar de caminar a la cocina, tendran que 
buscar una computadora. A mi me parece que es como matar moscas a canonazos. ^Que nos 
ahorrarfa?” 

Ingeniero de sistemas: “Tal vez nada, como lo has descrito. Incluso hasta el servicio 
podrfa empeorar. Pero asi no era lo que yo pensaba .” 

Analista: “^Entonces?” 

Ingeniero de sistemas: “Bueno. Suponga que cada mesero y mozo de piso llevan consigo 
una terminal. Una pequena, del tamano de la palma de su mano. Y tambien supon que no 
usamos cables. Tendrfamos una terminal de escritorio en la cocina y otra en la oficina del 
gerente.” 

Analista: “Ah, ya veo... El sistema del que hablas podrfa resolver muchas cosas. Por 
ejemplo, si el cliente hace sus drdenes, el mesero podrfa marcarlas en su computadora de 
mano y se irfan a una terminal en la cocina. Ello eliminarfa el paso, y los pasos, de cami- 
nar del area de servicio a la cocina.” 

Mesero: “Me gusta. ^Que tal si e l cliente casi ha acabado sus entremeses y se lo indico a 
la cocina apretando algo en la computadora que dicen? Ello me evitara el tener que ir y 
decirle al chef que termine de preparar el plato principal.” 

Chef: “Y asi vere el mensaje en la cocina. De hecho, todos mis asistentes podrfan ver el 
mensaje al mismo tiempo, y podrfamos tener los mensajes en una, dos o tres pantallas 
grandes. No tendre que ver cual asistente estaba cocinando que platillo ni decirles que tanto 
deberfan de haber avanzado. Elios podrfan tomar tal responsabilidad por si mismos.” 




Ingeniero de sistemas: “Y cuando terminen la orden, podrian enviar un mensaje al 
mesero para hac6rselo saber. No tendra que estar regresando a la cocina para verificar.” 

Mesero: “Huy, pues suena muy bien. Incluso podria enviarle una serial a un mozo de piso 
para que limpie una mesa. No tendre que buscar a uno. Elio podria agilizar mucho las 
cosas.” 

Restaurantero: “^Como podrian ustedes hacer esto?” 

Ingeniero de sistemas: “No se preocupe de ello por el momento ” 

Moderador: “Bueno, entonces nuestro sistema sera una red de area local inalambrica con 
computadoras palmtop para los meseros y los mozos de piso, y con computadoras de 
escritorio en la cocina y en la oficina del gerente. Pero nos estamos olvidando de algo.” 

Analista: “^De que?” 

Moderador: “De un nombre para el sistema.” 

Chef: “i,Que tal ‘EL EXPERTO CHEF?” 

Moderador: “^Y tiene algun significado en particular? ^Forman alguna sigla?” 

Chef: “No. Solo me gusto.” 

Analista: “^Que tal Red Interactiva Inalambrica para Restaurantes? Podriamos llamarla 
RIIR.” 

Moderador: “Bueno... No lo se.” 

Ingeniero de sistemas: “Bueno, tal vez podria ser Red Inalambrica para la Comunicacion 
Organizada. jMiren! Y ello deja las siglas RICO, que seria muy adecuado para el servi- 
cio en un restaurante.” 

Chef: “Me gusta.” 

Analista: “A mi tambien. El nombre deja entrever que el sistema nos enriqueceria a 
nosotros, y tiene un significado muy directo .” 

Moderador: “Entonces, ^Estamos de acuerdo con RICO? Bien, pienso que hemos termi- 
nado por el momento ” 

Preparacion para la recopilacion 
de las necesidades 

El equipo pasa los resultados de su reunion a los funcionarios corporativos. LaHudra no 
puede creer en su buena fortuna al explorar una nueva area. Nar esta completamente 
abrumado. Goniff ve visiones de signos monetarios que bailan ante sus ojos. Los tres le 
dicen al equipo que prosiga. 




Ahora que el equipo tiene una idea del sistema, ^podran iniciar su trabajo los progra- 
madores y los ingenieros de sistemas? Por supuesto que no. El equipo debera adaptar el 
sistema RICO a las necesidades de los usuarios, no a la tecnologfa. Aunque ya cuentan 
con algunas ideas de la reunion del equipo, aun no han expuesto el concepto de RICO a 
un grupo de empleados y gerentes para obtener informacion e ideas desde su punto de 
vista como usuarios. 

La siguiente accion GRAPPLE hace exactamente eso. En una sesion de Desarrollo con- 
junto de aplicaciones (JAD), el equipo obtendra y documentary las necesidades del sis- 
tema. Con esto, podran hacer algunas estimaciones de tiempo y dinero. 

La sesion JAD se realiza en una sala de conferencias. Encabezada por un moderador, se 
denomina sesion “conjunta” dado que incluira a miembros del equipo de desarrollo y a 
usuarios potenciales del sistema, asf como a expertos del dominio. Los miembros del 
equipo de desarrollo en esta reunion son dos analistas que toman notas, un modelador, 
dos programadores y un ingeniero de sistemas. Los usuarios potenciales son tres 
meseros, dos chefs, dos restauranteros y dos mozos de piso. 

El objetivo de esta reunion es producir un diagrama de paquetes que muestre los princi- 
pales segmentos de funcionalidad del sistema. Cada paquete representara un segmento y 
contendra casos de uso que detallaran de que se trata cada segmento de funcionalidad. 

Vamos a la sesion. 



La sesion JAD de necesidades 

Moderador: “Para empezar, quiero agradecerles a todos haber venido a nuestra sesion. 
Estas sesiones nos pueden llevar algo de tiempo, pero tambien pueden ser muy diver- 
tidas. Lo que intentamos hacer es conocer las necesidades para un sistema llamado 
RICO: Red Inalambrica para la Comunicacion Organizada ” 

“El concepto de RICO es muy directo. La forma en que lo imaginamos es que los meseros 
tendran en su poder una computadora palmtop y la utilizaran para comunicarse con la 
cocina y sus mozos de piso. Estos ultimos tambien tendran computadoras de este tipo y 
las utilizaran para comunicarse. La cocina tendra una terminal de escritorio y una o 
varias pantallas. El gerente tambien tendra una en su oficina. He aqui una figura de lo 
que estoy hablando.” (Vea la figura 18.5.) 

“Esperamos instalar a RICO en todos los restaurantes LNG, y queremos ayudarles a 
hacer su trabajo. Para lograrlo, necesitamos que nos digan que es lo que desean que haga 
el sistema. Es decir, si el sistema ya estuviera en funcionamiento ^que querrfan que 
hiciera?” 




Figura 18.5 

El sistema RICO. 




“Haremos esta pregunta una y otra vez. A1 final de la sesion, tendremos un conjunto 
organizado de necesidades con las que todos estaremos de acuerdo. Piensen que es su 
carta a Santa Claus. Nos basaremos en esa carta para crear un proyecto que los progra- 
madores utilizaran para generar el sistema. Hay algo que quisiera que tuvieran en cuenta: 
necesitamos la comprension e ideas de cada uno de ustedes, no importa cual sea el nom- 
bre de su puesto ” 

Analistal: “^Podrfamos empezar por imaginamos cuales serian los principales segmentos 
de funcionalidad?” 

Moderador: “Sf. ^Estan de acuerdo los miembros del grupo?” 

Restaurantero2: “Si, mire... Yo no estuve en los debates anteriores, pero creo que esto es 
una buena idea. ^Podriamos organizarlo de acuerdo a, por decir, las areas del restaurante? 
Es decir, las areas de servicio tienen ciertas necesidades, la cocina otras, el area de espera 
otras...” 

Moderador: “Es una posibilidad.” 

Analista2: “Hum... A1 ver los diagramas de procesos del negocio yo ya veo una organi- 
zation” 

Programadorl: “^Perdon?” 

Analista2: “Por tarea. El chef tiene que realizar ciertas cosas, el mesero otras, y asi ” 
Moderador: “Suena bien. ^Estariamos de acuerdo en organizarlo por tarea?” 

(Todos asienten). 





Moderador: “jBien! En los diagramas de procesos del negocio y de clases, las tareas que 
tenemos son Mesero, Chef, Mozo de piso, Asistente y Gerente .” 

Restaurantero2: “ ^No olvidaron algunas? No estan el encargado del guardarropa y el 
cantinero.” 

Restauranterol: “jVaya! ^Como se me pudieron olvidar?” 

Moderador: “Los agregare a nuestra lista, y utilizare los sfmbolos de paquetes del UML 
para estar al tanto.” (Yea la figura 18.6.) 



Figura 18.6 

Los paquetes de fun - 
cionalidad de RICO. 



Funcionalidad de RICO 




Modelador: “Ya estoy en ello. Agregue information a nuestros diagramas de clases. Ya 
estaba la clase EncargadoDelGuardarropa. Lo que agregue fue la clase Cantinero.” 

Restaurantero2: “Me pregunto que hace en su computadora laptop. £ Me podrfa mostrar 
sus, hum, ‘clases’?” 

Modelador: “Si, claro. Aqui estan.” (Yea la figura 18.7.) 











Figura 18.7 

Las clases 

EncargadoDelGuardar 
ropa v Cantinero. 



EncargadoDel 

Guardarropa 




imprimirVale 








guardarAbrigo() 

guardarSombrero() 

imprimirVale 




tomarOrdenDeBebida() 

prepararBebida() 

imprimirCuentaDeBar 



Restaurantero2: “Muy interesante. Espero que en algun descanso se de tiempo de expli- 
carme lo que significa ” 

Moderador: “Ahora que contamos con las piezas principales, ^alguien prefiere empezar 
con alguna tarea en particular?” 

Meserol: “^Que tal con la del Mesero?” 

Moderador: “Me parece adecuado. Bien, ^que tipo de funcionalidad quisiera ver en este 
paquete? Recuerden, miembros del grupo, que aunque tratemos una tarea que no sea la 
de ustedes, pueden participar. Todas las opiniones son bienvenidas ” 

Mesero2: “Quisiera poder tomar una orden en mi pequena computadora y enviarla a la 
cocina” 

Moderador: “Muy bien. ^Que mas?” 

Meserol: “Quisiera saber el grado de avance de una orden” 

Chef2: “^Puedo indicarle a un mesero cuando ya este lista su orden?” 

Moderador: “Si y si. Estos conceptos, como ven, los estoy escribiendo dentro de elipses 
rotuladas. Las llamare ‘casos de uso\ Les pediremos a algunos de ustedes que regresen y 
que nos ayuden a analizar tales casos de uso, pero ello sera en otra reunion ” 

El resultado 

La sesion JAD continuo por el resto del dia. Cuando los participantes terminaron, ya 
contaban con un conjunto de necesidades que aparecieron como casos de uso organiza- 
dos en los paquetes. 

Para el paquete mesero, los casos fueron: 

• Tomar una orden 

• Transmitir la orden a la cocina 

• Cambiar una orden 



• Recibir una notificacion de la cocina 




• Llevar un control del progreso de la orden 

• Notificar al chef el progreso de los clientes en sus alimentos 

• Totalizar una cuenta 

• Imprimir una cuenta 

• Llamar a un asistente 

• Llamar a un mozo de piso 

• Tomar una orden de bebida 

• Transmitir una orden de bebida al bar 

• Obtener un acuse de recibo 

• Recibir una notificacion del bar 

Para el paquete chef, los casos de uso fueron: 

• Almacenar una receta 

• Recuperar una receta 

• Notificar al mesero 

• Recibir una peticion del mesero 

• Dar acuse de recibo a una peticion del mesero 

• Indicar el periodo de preparation 

• Asignar una orden 

Los casos de uso del mozo de piso fueron: 

• Recibir una peticion del mesero 

• Dar acuse de recibo a una peticion 

• Indicar que una mesa ha sido limpiada 

Los casos de uso para el asistente fueron: 

• Recibir una peticion del mesero 

• Recibir una peticion del chef 

• Dar acuse de recibo de una peticion 

• Notificar que la peticion se ha completado 

Para el cantinero: 

• Capturar una receta de bebida 

• Obtener la receta de una bebida 

• Recibir una notificacion del mesero 




• Recibir una petition del mesero 

• Dar acuse de recibo de una petition 

• Notificar que la petition se ha completado 

Y para el encargado del guardarropa: 

• Imprimir un vale de abrigo 

• Imprimir un vale de sombrero 

La figura 18.8 muestra la forma en que todo lo anterior luce en el UML. 



Figura 18.8 

El diagrama de 
paquetes de 
funcionalidad. 




El modelador hara el desarrollo ulterior de los diagramas de clases mediante la adicion 
de dos clases y asociaciones como en la figura 18.9. 




Figura 18.9 

La information de 
las clases recien 
agregada. 




iAhora que? 

El documento de diseno que entregara el equipo a su cliente crece a pasos agigantados. 
Ahora incluye procesos del negocio, diagramas de clases y un conjunto de paquetes de 
funcionalidad. 

I Ahora empezara a codificar el equipo? En absoluto. En la siguiente hora empezaran a 
analizar el contenido de los paquetes. 



Resumen 

En el contexto de la reunion, el equipo de desarrollo ha generado una vision del sistema 
de computo para el restaurante del futuro. Los miembros del equipo decidieron que la 
agilizacion en la transmision de la information es la clave para el exito del sistema, y 
traen a eolation tipos de tecnologia para lograrlo. 

En una sesion JAD, el equipo de desarrollo se reune con usuarios potenciales y expertos 
de dominio para obtener los requerimientos del sistema. El resultado es un diagrama de 
paquetes en donde cada paquete representa una seccion principal de funcionalidad. Los 
casos de uso dentro de un paquete se basan en tal funcionalidad. 





Preguntas y respuestas 

P ^Podria ser que algunos de los participantes de la sesion JAD sean los mismos 
que participaron en la reunion anterior en equipo? 

R Si, y, de hecho, es recomendable. Tales personas podrfan recordar detalles vitales 
que podrfan no ser muy claros en las minutas. 

P Vi que los senores LaHudra, Nar y Goniff no participan en tales reuniones. 
^Podria alguien de tal nivel tomar parte en las reuniones y las sesiones JAD? 

R Estos en particular no. Sin embargo, en algunas empresas, los altos directivos 
podrfan participar de manera activa al menos en parte de una sesion. Es dificil que 
un alto directivo tome parte en toda una sesion JAD. 

P ^Siempre se dara el caso de que se tenga que organizar al sistema por tareas, 
como lo hicimos en este dominio? 

R No, no siempre. Aqui se hizo asi porque fue conveniente para este dominio. De 
hecho, podrfamos buscar una forma altemativa de hacerlo si nos concentramos en 
ello. Otros tipos de sistemas podrfan requerir un trato distinto. Por ejemplo: un £rea 
de asistencia podrfa tener Recepcidn de llamadas, Resolution de problemas y 
Regreso de llamadas como paquetes. Nuevamente, dentro de cada paquete, tendrd 
un conjunto de casos de uso. 



Taller 

Verifique su conocimiento en la recopilacion de necesidades y localice las respuestas en 
el Apendice A, “Respuestas a los cuestionarios”. 

Cuestionario 

1 . ^Como hemos representado las necesidades del sistema? 

2. ^Una vez que se hace el analisis del dominio ya finaliza el modelado de clases? 

3. <?,Que es el “tiempo muerto”? 

Ejercicio 

Continue con el dominio de la Biblioteca. ^Cuales son los principales paquetes de 
funcionalidad? ^Cuales son los casos de uso que los componen? 



Hora 1 9 

Desarrollo de los casos 
de uso 

Ahora que ha visto lo que esta involucrado en la recopilacion de necesidades, 
veremos el analisis de tales necesidades y las llevaremos a cabo en un 
sistema. 

En esta hora se trataran los siguientes temas: 

• Cuidado y provision de casos de uso 

• La especificacion de descripciones, condiciones previas y resultantes. 

• La especificacion de pasos 

• La diagramacion de los casos de uso 

Los casos de uso del diagrama de paquetes de la hora 18, “Recopilacion de 
las necesidades del sistema”, nos dio una buena idea de lo que el sistema 
tendra que hacer. El equipo tendra que llevar a cabo cada uno de ellos. Poco 
a poco han pasado de comprender el dominio a comprender el sistema. Los 
casos de uso establecieron el puente. 

Si cree que el proyecto del desarrollo del sistema se orienta a los casos de 
uso, ya habra comprendido todo el proceso. 



Observe que en ningun momento de la sesion JAD el equipo de desarrollo hablo de la 
forma en que el sistema realizaria todas las actividades indicadas en los diversos casos de 
uso. La idea fue la de enumerar todos los casos de uso posibles. Conforme se realicen los 
casos de uso en esta hora, vera la forma en que los componentes del sistema RICO 
empezar&n a materializarse. En este punto del desarrollo, el sistema empieza a ser el cen- 
tro de atencidn. 

Vamos a ponemos en los zapatos del equipo de desarrollo y veremos algunos de los 
casos de uso obtenidos. 

Cuidado y provision de los casos de uso 

Para analizar a los casos de uso, tendremos que realizar otra sesion JAD. El debate en 
esta sesidn se orienta a derivar un andlisis para cada caso de uso. 

A modo de advertencia: la sesion JAD de los casos de uso es, por lo general, la m&s 
compleja, dado que pide a los participantes (usuarios potenciales del sistema terminado) 
que se conviertan en analistas. En su propio nicho, cada uno es un experto del dominio, y 
tendrd que profundizar en su experiencia. Por lo general, no estan acostumbrados a 
expresar o analizar su conocimiento. De hecho, tambien es probable que tampoco hayan 
formado parte de algun proyecto de diseno, y que no se sientan muy a gusto al intentar 
especificar lo que un sistema deberfa hacer para ayudarles en su trabajo. 

Para reducir estas presiones, es mejor organizar la sesidn JAD para que el equipo trate 
con un grupo a la vez; por ejemplo: solo los meseros. De esa forma, los dem&s no estardn 
ociosos mientras los meseros analizan sus casos de uso. Quienes conocen las generali- 
dades del dominio, los restauranteros, podrfan dar una mano en todos los grupos. Una 
seleccidn de usuarios serfa adecuada cuando se trate el tema del paquete del Cliente. 

Son muchos los casos de uso, y para no extendemos mucho en esta hora, nos enfocare- 
mos en los primeros nueve de ellos, propios del paquete Mesero. Luego de que vea c6mo 
se hardn tales analisis, podra hacer el resto de los casos de uso de los Meseros, asi 
como los de los demas paquetes. 

El analisis de los casos de uso 

Por lo que se menciono anteriormente (hora 7, “Diagramas de casos de uso”), recuerde 
que, cada caso de uso es una coleccion de situaciones, y cada una de estas es una secuen- 
cia de pasos. Para cada escenario en cada caso de uso, queremos mostrar: 

• Una breve descripcidn del escenario 

• Conjeturas del escenario 




• El actor que inicia el caso de uso 

• Condiciones previas para el caso de uso 

• Pasos relacionados con el sistema en el escenario 

• Condiciones resultantes una vez terminado el escenario 

• El actor beneficiado del caso de uso 




En su analisis tambien podra incluir cualquier condicion excepcional o alter- 
nativas. No obstante, los presentes escenarios se han mantenido simples. 



Ninguna forma especifica es “correcta” para establecer un analisis de casos de uso. Los 
elementos que he listado establecen, por lo general, un panorama del caso de uso. 




En su documento de diseno (el que le da a su cliente y programadores), cada 
uno de estos analisis de casos de uso deberan estar en paginas por separado. 
Posiblemente quiera incluir un diagrama del caso de uso, con todo y actores, 
en esta pagina. 



Los pasos, en el escenario, que estan relacionados con el sistema son muy importantes. 
Mostraran la forma en que se supone que funcionara el sistema. Cuando los participantes 
de la sesion JAD nos digan los pasos, de hecho nos estaran diciendo como va a lucir el 
sistema. Despues de esta sesion JAD, deberfamos tener una firme idea de los compo- 
nentes del sistema. 

Tambien es importante hacer conjeturas. En la lista de conjeturas, podra indicar algunas 
consideraciones de diseno, como lo vera posteriormente. 

Esto era lo que quise decir cuando dije que el proyecto serfa “orientado a casos de uso”. 
Los casos de uso crearan, a fin de cuentas, la ruta de acceso al sistema. 

paquete Mesero 

La clase Mesero se distingue por ser la de mayor actividad, lo cual no deberfa sorpren- 
demos, dado que el mesero interactua practicamente con las demas clases. 





Los casos de uso del Mesero son: 

• Tomar una orden 

• Transmitir la orden a la cocina 

• Cambiar una orden 

• Recibir una notification de la cocina 

• Sondear el progreso de la orden 

• Notificar al chef del progreso de los clientes en sus alimentos 

• Totalizar una cuenta 

• Imprimir una cuenta 

• Llamar a un asistente 

• Llamar a un mozo de piso 

• Tomar una orden de bebida 

• Transmitir una orden de bebida al bar 

• Obtener un acuse de recibo 

• Recibir una notiflcacion del area del bar 

Tomar una orden 

Empecemos con “Tomar una orden”. Vamos a preguntarle a los meseros experimentados, 
para que nos den una descripcion, conjeturas, condiciones previas, pasos y condiciones 
resultantes. El paquete y subpaquete ya indica al actor que inicia (Mesero) y al benefi- 
ciado (Cliente). 

Una buena descripcion en una sola frase podrfa ser: “El mesero captura la orden del 
cliente en la palmtop y la transmite a la cocina ” Se asume que un cliente desea un 
platillo, que ha leido el menu y que ya hizo su eleccidn. Tambien se puede asumir que 
la palmtop del mesero cuenta con una interfaz para capturar drdenes. 

Las condiciones previas son que un cliente se haya sentado y haya leido el menu. La 
condition resultante es que tal pedido se haya capturado en RICO. 

Los pasos en el caso de uso son: 

1. En la palmtop, el Mesero activa la interfaz para capturar una orden. 

2. Aparece la interfaz para capturar drdenes. 

3. El Mesero registra la selection del Cliente hecha del menu en RICO. 

4. El sistema transmite la orden a la PC de la cocina. 




Aunque hemos asumido que ya hay una interfaz para registrar ordenes, aun no hemos 
especificado como luciria o como seria el proceso ffsico de registrar la orden. Todavia no 
sabemos como lucira la interfaz de la PC de la cocina, ni hemos dicho nada de los 
detalles tecnicos de transmitir una orden. 

El punto es que, conforme ponemos de manifiesto nuestras conjeturas en cuanto al di- 
seno, empezamos a tener una idea de lo que se supone que debe hacer el sistema y 
empezamos a dar forma a nuestras ideas para ponerlo en practica. Los pasos en los casos 
de uso nos fuerzan a asumir la idea acerca de los componentes del sistema. Recuerde que 
los casos de uso pretenden mostrar como se ve el sistema para un usuario. 

Transmitir la orden a la cocina 

^Listo para otro? Este sera incluido en (esto es, “usado por”) al menos dos casos de uso: 
la anterior y “Cambiar una orden”. 

La descripeion es: “Tomar una orden que ha sido registrada en la palmtop, colocarla 
en la red inalambrica y enviarla a la PC de la cocina”. Se asume que ya tenemos medios 
para comunicar la orden (mediante una red inalambrica) y, nuevamente, que contamos 
con una interfaz para registrar una orden. ^Tenemos que repetir esta conjetura? Si. Cada 
caso de uso aparecera eventualmente en una pagina por separado en el documento de dis- 
eno, lo que servira como una referenda del sistema. Para mayor claridad, las conjeturas 
deberfan aparecer en cada caso de uso, aun si tenemos que repetirlas en cada uno de 
ellos. 

La condicion previa es una orden registrada en una palmtop. La condicion resultante es 
que la orden llegue a la cocina. El actor beneficiado es el Cliente. 

Los pasos son: 

1 . Hacer clic en un boton en la interfaz para el registro de ordenes indica “Enviar a la 
cocina”. 

2. RICO transmitira la orden mediante la red inalambrica. 

3. La orden liega a la cocina. 

4. La interfaz del usuario para registrar las ordenes en la palmtop indica que la orden 
ha llegado a la cocina. 

Claro estd que tendremos que modificar nuestro diagrama de casos de uso para el subpa- 
quete Cliente. Tiene que mostrar la dependencia «incluir» entre este caso de uso y 
“Tomar una orden”, y entre este caso de uso y “Cambiar una orden”. La figura 19.1 
muestra los diagramas actualizados del caso de uso para el paquete Mesero. 



Figura 19.1 



Los diagramas actua- 
lizados de casos de uso 
para el paquete 
Mesero. 




Cambiar una orden 

Dentro de este contexto, vayamos a “Cambiar una orden”. La descripcion es “Modi- 
ficar una orden ya registrada en RICO”. Se asume que ya se ha registrado y enviado a 
la cocina una orden y que, subsecuentemente, el cliente desea cambiarla. Tambi6n 
asumiremos que RICO cuenta con una base de datos de ordenes que muestra al mesero 
quien ha capturado cada orden y la mesa de donde provino, que el mesero podra acceder 
a tal base de datos en la palmtop, que RICO puede transmitir y recibir de la palmtop a 
la PC de la cocina, y que la palmtop tiene una interfaz de usuario capaz de cambiar 
una orden. 

La condicion previa es la orden registrada con anterioridad. La condicion resultante es 
que la orden modificada haya llegado a la cocina. El actor beneficiado es el Cliente. 

Los pasos en este caso de uso son: 

L En la palmtop, el mesero activa la interfaz del usuario para cambiar una orden. 

2. La interfaz del usuario trae una lista de ordenes realizadas y enviadas a la cocina 
por el mesero. 

3. El mesero selecciona la orden por cambiar. 

4. El mesero registra la modification a la orden. 

5. El sistema transmite la orden a la PC de la cocina. 

El paso 5 incluye al caso de uso anterior “Transmitir la orden a la cocina”. 





Sondeo del progreso de la orden 

Como podra recordar, los debates anteriores respecto al restaurante del futuro incluyeron 
la posibilidad de descubrir en que momento la orden de un cliente saldrfa de la cocina. 
Este caso de uso hace exactamente eso. Si se instaura en el sistema se facilitara enorme- 
mente el trabajo del mesero. 

La descripcion es: “Sondear el progreso (el tiempo para completar) de una orden que ya 
se haya registrado en RICO”. Se asume que ya se ha realizado, registrado y enviado una 
orden a la cocina, y que el cliente desea saber cuanto m&s esperara para que llegue su 
platillo. Repetimos dos conjeturas de diseno anteriores: una base de datos de pedidos y la 
facultad de transmitir mensajes entre la palmtop y la PC de la cocina. Tambien asumimos 
una interfaz del usuario en la palmtop para el sondeo de las ordenes y otra en la PC de la 
cocina con el mismo proposito. 

La condicidn previa es la orden registrada con anterioridad. La condition resultante es 
que el estado de la orden ha llegado a la palmtop del mesero. El actor beneficiado es el 
Cliente. 

Los pasos son: 

1. El mesero activa la interfaz en la palmtop para sondear una orden registrada. 

2. La interfaz le muestra al mesero una lista de las drdenes que tiene registradas en la 
cocina. 

3. El mesero elige la orden que desea sondear. 

4. El sistema transmite el mensaje de sondeo a la PC de la cocina. 

5. La PC de la cocina recibe el mensaje. 

6. El chef selecciona la orden de la cual se quiere conocer su avance. 

7. El chef teclea un tiempo estimado para completar la orden. 

8. El sistema transmite el tiempo estimado a la palmtop del mesero. 

Notificar al chef del progreso de los dientes 
en sus alimentos 

A partir de este caso de uso, utilizare subtitulos para indicar los aspectos del analisis del 
caso de uso y vinetas para establecer frases para cada subtitulo con dos excepciones: 
Seguire numerando los pasos y no utilizare vinetas para la descripcion. 

Descripcion 

Mediante la red, el mesero le indica al chef que un cliente ya casi ha finalizado con su 
entremes. 




Conjeturas 

• El mesero se encuentra en el area de servicio del cliente 

• El mesero puede medir el progreso del cliente 

• El sistema cuenta con una interfaz para el estado del cliente 

• El sistema transmite mensajes de la palmtop a la PC de la cocina y viceversa. 

Condiciones previas 

• El cliente ha fmalizado de manera parcial el entremes 

Condiciones resultantes 

• El chef ha iniciado los pasos finales para completar el plato principal 

Pasos 

1. En la palmtop, el mesero activa la interfaz para el estado del cliente. 

2. La interfaz de usuario trae una lista de las mesas en el Irea de servicio del mesero. 

3. El mesero elige la mesa indicada. 

4. El mesero envia un mensaje de “ya casi termino con el entremes” a la PC de la 
cocina. 

5. La PC de la cocina recibe el mensaje. 

6. El mesero obtiene un acuse de recibo de la PC de la cocina. 

Este ultimo paso utiliza el caso de uso “Acuse de recibo”, que se encuentra en el paquete 
Mesero. La figura 19.2 le muestra un diagrama de este caso de uso. 



Figura 19.2 

Diagrama de caso de 
uso para “ Notificar al 
chef del progreso de 
los clientes en sus 
alimentos ”. 




Cliente 





Actor beneficiado 

• Cliente 

Totalizar una cuenta 

Description 

Sumar los elementos en la orden. 

Conjeturas 

• Existe una base de datos de pedidos accesibles mediante la palmtop 

• Cada elemento de la orden se relaciona con su precio 

Condiciones previas 

• El servicio ya ha terminado con sus alimentos 

Condiciones resultantes 

• Se totaliza la cuenta 

Pasos 

1. El mesero trae una lista de ordenes activas en la palmtop. 

2. El mesero elige la orden adecuada. 

3. El mesero presiona un boton en la palmtop para totalizar la cuenta. 

4. El sistema calcula el total de los precios en la cuenta. 

Actor beneficiado 

• Cliente 

Imprimir una Cuenta 

Aunque podrfa parecer trivial, es una parte importante de la transaction. 

Description 

Imprimir la cuenta totalizada. 

Conjeturas 

• Una impresora conectada a la red inalambrica en el area de servicio 

Condiciones previas 

• Una cuenta totalizada 



Condiciones resultantes 

• Una cuenta impresa 

Pasos 

1 . El mesero presiona un boton para imprimir la cuenta. 

2. La impresora conectada a la red en el £rea de servicio imprime la cuenta. 

3. El mesero presiona un boton en la palmtop para quitar esta orden de la lista de 
drdenes activas. 

Actor beneficiado 

• Cliente 

Llamar a un Asistente 

Description 

Solicitar a un asistente que limpie la mesa para el siguiente cliente. 

Conjeturas 

• El sistema permite una comunicacidn inaldmbrica entre dos empleados en 
movimiento 

• El sistema cuenta con una interfaz para enviar un mensaje a un asistente 

Condiciones previas 

• Una mesa vacia tendrd que ser limpiada y preparada 

Condiciones resultantes 

• El asistente llega a la mesa para limpiarla y prepararla 

Pasos 

1. El mesero activa la interfaz para enviar un mensaje a un asistente. 

2. El mesero obtiene un acuse de recibo del asistente. 

Como en el caso de uso “Notificar al chef del progreso de los clientes en sus alimentos”, 
el ultimo paso utiliza el caso de uso “Acuse de recibo”. 

Actor beneficiado 



• Asistente 




A1 analizar este caso de uso, asi como los casos de uso en el paquete del Asistente, tal 
vez pensemos que separar la clase Asistente en dos, AsistenteMesero y AsistenteChef, 
serfa una buena idea (aclararia las cosas). ^Podrfan ambas ser clases secundarias de una 
clase abstracta Asistente? Podrian, pero posiblemente no se obtendrfa mucho de estable- 
cer esta clase abstracta. 

La creation de estas dos clases requiere una revision al an&lisis del dominio. Tendremos 
que volver a trabajar los diagramas de clases, en particular el diagrama de Empleado, 
como muestra la figura 19.3. 



Figura 19.3 

El diagrama actua - 
lizado de la clase 
Empleado. 




Tambien tendnamos que actualizar nuestros diagramas de paquetes para incluir el de 
Asistente Mesero y Asistente Chef. 

Esto es un eiemplo de la forma en que los segmentos de GRAPPLE se intercomunican. 
Los conocim ientos obtenidos durante el analisis de los casos de uso han ayudado a 
desarrollar el analisis del dominio. 

Casos de uso restantes 

Los restantes casos de uso en el paquete Mesero son muy similares a los que hemos 
analizado. Le dejare como ejercicio finalizar el analisis de este paquete (vea el ejercicio 1 
del taller). 

Componentes del sistema 

Un aspecto importante del analisis del caso de uso es que empezd a descubrir compo- 
nentes del sistema. Antes de finalizar con esta hora, tome nota de los componentes que 
hemos visto durante nuestro analisis de los casos de uso en el paquete Mesero. Los vera 
en la seccidn Conjeturas de cada analisis de los casos de uso (habra otros componentes 
que apareceran cuando haga los ejercicios). 






En el lado del software, es obvio que son necesarias varias interfaces de usuario. RICO 
necesitara interfaces del usuario basadas en palmtops para registrar ordenes, cambiarlas, 
sondearlas, dar el estado del cliente y enviar mensajes para un asistente. Como buena 
medida, algo como una interfaz tipo “pagina principal” sera necesario para tener organi- 
zadas las demas interfaces. RICO tambien necesitara una interfaz del usuario en la PC de 
la cocina para permitir ai chef verificar el avance de una orden. 

Tambien parece que necesitaremos una base de datos que contenga a todos los pedidos. 
Cada registro contendra la mesa, el pedido, la hora en que se realizo, el mesero, si el 
pedido esta activo, y cosas asi. 

Del lado del hardware, necesitaremos una red inalambrica, palmtops para los empleados 
en movimiento (meseros, asistentes y mozos de piso) y una PC de escritorio en la cocina, 
as! como otra en la recepcion. Necesitaremos una impresora conectada a la red en cada 
drea de servicio. Probablemente, tambien necesitaremos una palmtop y una impresora 
para el encargado del guardarropa. 

Ya esta tomando forma un mejor documento de diseno. En la hora siguiente, profun- 
dizara aun mas en los casos de uso. 

Resumen 

No basta con listar todos los casos de uso. Un equipo de desarrollo debera comprender 
cada uno detalladamente para empezar a comprender el sistema. En esta hora vimos 
detalladamente el andlisis de cada parte de un caso de uso. 

Un analisis de casos de uso involucra la especificacion de una description del propio 
caso de uso, derivar las condiciones previa y resultante, y especificar los pasos. Un 
aspecto importante del analisis de los casos de uso es que los componentes del sistema 
empiezan a ser evidentes. 

Preguntas y respuestas 

P En el segmento inicial de GRAPPLE, note que paso por alto la action 
“Identification de los sistemas cooperativos”. ^A que se debe? 

R Como recuerda, este equipo de desarrollo initio un proyecto sin precedentes. No 
hay sistemas cooperativos. No obstante, el siguiente sistema que alguien disene 
para Restaurantes LNG tal vez tendrfa que acceder a RICO de alguna forma. 

P En esta hora modified los diagramas de casos de uso y el de clases. ^Esto 
sucede con frecuencia? 

R Asi es. No debera ser reacio a hacer modificaciones conforme evolucione su 
conocimiento. La lista original de casos de uso capturo todo el conocimiento en 
cierto punto del proyecto, y captura una imagen de tal momento. Los diagramas 
modificados representaran las ideas subsecuentes del equipo de desarrollo. 




Taller 

El taller para esta hora verificara su conocimiento para realizar casos de uso. Para ver 
respuestas reales, vea el apendice A, “Respuestas a los cuestionarios”. 

Cuestionario 

1. ^Cuales son las partes de un diagrama de casos de uso tfpico? 

2. que se refiere que un caso de uso “incluya” (o “utilice”) a otro? 

Ejercicios 

1. Genere el diagrama de casos de uso para “Llamar a un mozo de piso”. 

2. Analice los restantes casos de uso del paquete Mesero, y dibuje sus diagramas. 

3. Analice los casos de uso del paquete Chef, y dibuje los casos de uso. 

4. Haga lo mismo para los paquetes Cantinero, Asistente y Mozo de piso. 

Analice los casos de uso que haya obtenido de su proyecto Biblioteca. 



Hora 20 

Orientacion a las 
interacciones y cambios 
de estado 

A continuation profundizara en los casos de uso analizados en la hora ante- 
rior. Los utilizara como fundamento para comprender las partes del sistema 
y la forma en que se comunican entre si. 

En esta hora se trataran los siguientes temas: 

• Las partes funcionales del sistema 

• Modification de los casos de uso 

• Analisis de la colaboracion entre las partes funcionales 

El analisis de los casos de uso de la hora anterior es un gran avance para 
hacer realidad el sistema RICO. No obstante, el analisis aun esta muy lejos 
de permitir que se empiece con la codification. 

Analizar los casos de uso ha ayudado a visualizar las partes funcionales del 
sistema. Aunque ahora sabemos mucho de ellos, aun tenemos que modelar 
la forma en que las partes funcionales se comunicaran entre si y la forma (y 
momento) en que cambiaran de estado. Dar esta information a los progra- 
madores facilitara su trabajo. Tendran una vision de la forma de codificar las 
clases y hacer que trabajen en conjunto. 



Las partes funcionales del sistema 

Una forma de empezar es enumerar los componentes sugeridos del sistema en cada 
paquete de casos de uso. Aunque no hemos analizado de manera explfcita todos los casos 
de uso en todos los paquetes en la hora anterior, aun podrfamos obtener los componentes 
que se asumen en ellos. Claro que en un verdadero proyecto de desarrollo, un equipo de 
desarrollo deberfa analizar todos los casos de uso antes de continuar. 

El paquete Mesero 

A1 finalizar la hora anterior, enumeramos las partes de software del sistema de acuerdo 
con nuestro analisis de los primeros nueve casos de uso del paquete Mesero: en las palm- 
tops, RICO necesitara interfaces para el registro de drdenes, su modificacion, su control, 
el estado de los clientes y el envio de mensajes. Tambien sera necesaria una pantalla 
principal en la interfaz. Nuestro analisis trajo a la luz la necesidad de una interfaz para 
ver el avance de los pedidos en la PC de la cocina. RICO necesitara una base de datos 
para contener a todas las ordenes. 

Los casos de uso que no analizamos tambien sugieren componentes del sistema. Para 
refrescar su memoria, esos casos eran: 

• Llamar a un mozo de piso 

• Tomar una orden de bebida 

• Transmitir una orden de bebida al bar 

• Obtener un acuse de recibo 

• Recibir una notificacion del bar 

Los casos de uso sugieren algunos componentes evidentes. El primero nos indica que 
algo en la interfaz del Mesero (como una pantalla dedicada) tiene que permitir la llamada 
a un mozo de piso. El segundo, que se necesita una pantalla para obtener una orden de 
bebidas (similar a la que se usa para tomar una orden de alimentos). La interfaz debe 
poder obtener un acuse de recibo (para mostrar, por decir, que el mozo de piso ha 
recibido la petition) y recibir un mensaje del bar que indique que esta lista la bebida. 

Debido al trabajo de un mesero, no debe sorprendemos que los componentes primor- 
diales en este paquete son interfaces relacionadas con el registro de drdenes, asi como la 
reception y envio de mensajes. 




El paquete Chef 

Los casos de uso del paquete Chef son: 

• Almacenar una receta 

• Obtener una receta 

• Notificar al mesero 

• Recibir una peticion del mesero 

• Dar acuse de recibo a una peticion del mesero 

• Indicar el periodo de preparacion 

• Asignar una orden 

^Que componentes sugieren estos casos de uso? Nuevamente, algunos vienen a la mente 
de manera evidente. 

El paquete Mozo De Piso 

Los casos de uso para el mozo de piso son: 

• Recibir una peticion del mesero 

• Dar acuse de recibo a una peticion 

• Indicar que una mesa ha sido limpiada 

El paquete Asistente Mesero 

Como recordara, decidimos dividir el paquete Asistente en Asistente Mesero y Asistente 
Chef. Los casos de uso del Asistente Mesero serfan: 

• Obtener una peticion del mesero 

• Dar acuse de recibo a la peticion 

• Notificar que se ha completado la peticion 

El paquete Asistente Chef 

Los casos de uso del Asistente Chef serfan: 

• Obtener una peticion del chef 

• Dar acuse de recibo a la peticion 

• Notificar que se ha completado la peticidn 



Tal vez podrfa pensarse que no es necesaria una computadora para un asistente de chef 
dado que trabaja de forma muy cercana al chef en la cocina. No obstante, si la cocina es 
muy grande, la comunicacion electronica podrfa ser una buena idea. 

El paquete Cantinero 

Los casos de uso del Cantinero son: 

• Capturar la receta de una bebida 

• Obtener la receta de una bebida 

• Recibir una notificacion del mesero 

• Recibir una peticion del mesero 

• Dar acuse de recibo de una peticion 

• Notificar que la peticion se ha completado 

Estos casos de uso son similares a los del paquete del Chef, y los componentes de soft- 
ware que sugieren tambien lo son, El hardware es similar, a su vez: detras de una barra, 
una PC de escritorio podrfa tener mas sentido que una palmtop. 

Necesitamos una base de datos de recetas para bebidas y una interfaz que permitan un 
facil acceso a ella (tanto para capturar como para obtener recetas). La interfaz para el 
cantinero tiene que mostrar una notificacion proveniente del mesero (de que la mesa de 
un cliente esta lista) y una peticion de una bebida tambien proveniente del mesero. El 
cantinero tendra que enviar un acuse de recibo de que la peticion se ha recibido y, tam- 
bien, notificar al mesero que la bebida esta lista. 

El paquete Encargado Del Guardarropa 

Los casos de uso del Encargado Del Guardarropa son: 

• Imprimir un vale de abrigo 

• Imprimir un vale de sombrero 

Los componentes de software en la palmtop del encargado del guardarropa deberfan 
incluir una interfaz que permita la impresion del vale adecuado. El vale debera incluir la 
hora y una descripcion del artfculo. Posiblemente tambien queramos tener una base de 
datos de elementos almacenados. 

Colaboracion en el sistema 

En este punto del proyecto, la tarea sera mostrar la forma en que los componentes inter- 
actuan para completar cada caso de uso. Modelaremos tales interacciones para un par de 
casos de uso en el paquete del Mesero. El conjunto de casos de uso es demasiado grande 
para que los veamos todos; pero en un proyecto real, un equipo de desarrollo hara justa- 
mente eso. 





Recuerde que, como dije antes: Detras de cada caso de uso se esconde un 
diagrama de interacciones. 



Tomar una orden 

Empecemos con el caso de uso “Tomar una orden”. De lo desprendido en la hora 19, los 
pasos son: 

1. En la palmtop, el Mesero activa la interfaz para capturar una orden. 

2. Aparece la interfaz para capturar ordenes. 

3. El Mesero registra la seleccion del Cliente hecha del menu en RICO. 

4. El sistema transmite la orden a la PC de la cocina. 

En el modelo que desarrollamos en la hora anterior, este caso de uso incluye a 
“Transmitir la orden a la cocina”, cuyos pasos son: 

1 . Hacer clic en un boton en la interfaz para el registro de ordenes indica “Enviar a la 
cocina”. 

2. RICO transmitira la orden mediante la red inalambrica. 

3. La orden llega a la cocina. 

4. La interfaz del usuario para registrar las ordenes en la palmtop indica que la orden 
ha llegado a la cocina. 

Un diagrama de secuencias podria mostrar bastante bien esta colaboracion (igual lo 
haria un diagrama de colaboraciones, mismo que le pedire que genere en el ejercicio 1 ). 
La preparacion del diagrama nos fuerza a enfocar nuestra imagination de varias formas. 

Para empezar, cuando el mesero toma la orden de un cliente, creara algo: juna orden! Tal 
orden es un objeto en el sistema RICO (a su vez, es una instancia de una clase, Orden, 
proveniente de nuestro analisis del dominio en la hora 17, “Elaboration de un analisis 
del dominio”). El chef la usara como orientation para iniciar y realizar un conjunto de 
acciones. El mesero totalizara una cuenta de acuerdo con ella. El cliente pagara la 
cuenta. Asi, esta orden generada es un elemento importante. 

A su vez, si examina los casos de uso “Cambiar una orden” y “Sondear el progreso de 
la orden” (como lo haremos en un momento), vera que se hace referenda a una lista 
de ordenes. Esta lista se habra obtenido de una base de datos de ordenes, misma que 
mencione al finalizar la hora 19. ^Como se captura la orden en la base de datos? Bien, 
pues ello debera ocurrir en este caso de uso. 




Podemos enfocar nuestra imagination de otra forma. En el caso de uso incluido, el ter- 
mino “cocina” es un poco vago. Dado que estamos modelando componentes de software, 
tendremos que pulir lo que queremos decir aqui. Imaginar como podria funcionar todo 
nos llevara a una forma donde el sentido comun establecera que la orden debera mostrarse 
de algun modo en la interfaz del chef en la PC de la cocina. El como ocurra no es algo 
que en este momento debera ocupamos. 

Luego de que hemos pensado en lo anterior, el caso de uso “Tomar una orden” luciria 
asf: 

1. En la palmtop, el Mesero activa la interfaz para capturar una orden. 

2. Aparece la interfaz para capturar ordenes. 

3. El Mesero registra en RICO la selection del Cliente hecha del menu. 

4. RICO genera una orden. 

5. Incluir(Transmitir una orden a la cocina). 

6. El sistema guarda la orden en la base de datos de ordenes. 




"RICO" y "el sistema" son sinonimos. 



Observe el recurso utilizado en el paso 5 que indica la inclusion del caso de uso 
“Transmitir una orden a la cocina”. 

La “base de datos de pedidos” emplaza nuestra imagination hacia el lado del hardware. 
Esta base de datos debe encontrarse en una computadora, pero no hemos establecido una. 
Una posibilidad serfa contar con un equipo de computo central que tuviera esta base de 
datos y la hiciera accesible a las demas maquinas de la red. 

Mientras estamos en esto, debemos expandir el caso de uso “Transmitir la orden a la 
cocina” e incluir la modification respecto a la interfaz del chef. Dado que tiene un paso 
que establece un mensaje en la palmtop del mesero que indica la reception de la orden 
en la cocina, debemos agregar un paso que haga que el sistema envie un mensaje de la 
PC de la cocina a la palmtop. Asi, los pasos serfan: 

1. Hacer clic en un boton en la interfaz para el registro de ordenes indica “Enviar a la 
cocina”. 

2. RICO transmitira la orden mediante la red inalambrica. 

3. La orden llegara a la interfaz del chef en la PC de la cocina. 

4. RICO enviara un mensaje de la cocina a la interfaz de la palmtop que acuse el 
recibo de la orden. 

5. La interfaz del usuario, para registrar las ordenes en la palmtop, indicara que la 
orden ha llegado a la cocina. 




Estas modificaciones a los casos de uso son solo dos ejemplos mas de la forma en que 
una fase de un proyecto puede influenciar a otra. En este contexto, la preparation de nue- 
stros diagramas de secuencias nos ayudaron a pulir nuestra idea de los casos de uso con 
la base de esos diagramas. 

La figura 20. 1 le muestra el diagrama de secuencias que captura nuestra idea de este caso 
de uso. Para recordar lo que vio de los diagramas de secuencias, los objetos que estan 
colocados en la parte superior de el representan a los componentes en este caso de uso. 

El objeto Orden se genera durante el caso de uso, y por ello esta bajo los otros dos. El 
mensaje que apunta hacia el tiene un estereotipo «crear». La linea punteada que parte de 
cada objeto representa la “linea de vida de un objeto”, misma que avanza hacia abajo 
verticalmente. Los pequenos rectangulos en los tiempos de actividad se llaman “activa- 
ciones”. Cada activation representa al periodo en el que un objeto realiza una action. 



Figura 20.1 

El diagrama de 
secuencias de “ Tamar 
una orden 




Vea el cambio de estado en el primer tiempo de actividad. Intenta aclarar la forma en que 
una interfaz maneja un tipo especial de actividad. Podrfamos incluir todos los cambios de 
estado posibles como diagramas de estados por separado, pero serfa excesivo. El colocarlos 
en diagramas de secuencias (al menos en este dominio) aparentemente es mas sencillo. 




En un diagrama de secuencias, una flecha de mensaje con una linea pun- 
teada representa a un mensaje devuelto. 










Cambiar una orden 

Intentemos con otra. En la hora anterior, los pasos de caso de uso “Cambiar una orden” 
fueron: 

1. En la palmtop, el mesero activa la interfaz del usuario para cambiar una orden. 

2. La interfaz del usuario trae una lista de ordenes realizadas y enviadas a la cocina 
por el mesero. 

3. El mesero selecciona la orden por cambiar. 

4. El mesero registra la modificacion a la orden. 

5. El sistema transmite la orden a la PC de la cocina. 

Nuevamente, la preparation del diagrama nos ayuda a pulir nuestra imaginacidn y modi- 
ficar de cierto modo al caso de uso. Luego del paso 4, sin duda queremos que el sistema 
cree una orden modificada. Luego del paso 5, el sistema deberia registrar la orden modi- 
ficada en la base de datos de ordenes. 

Con ello, el nuevo caso de uso deberia ser: 

1. En la palmtop, el mesero activa la interfaz del usuario para cambiar una orden. 

2. La interfaz del usuario trae una lista de ordenes realizadas y enviadas a la cocina 
por el mesero. 

3. El mesero selecciona la orden por cambiar. 

4. El mesero registra la modificacion a la orden. 

5. RICO crea una orden de acuerdo con la modificacion a la anterior. 

6. Incluir(Transmitir una orden a la PC de la cocina). 

7. El sistema guarda la orden modificada en la base de datos de ordenes. 

Nuevamente, utilizamos el recurso para indicar la inclusion de un caso de uso. 

La figura 20.2 le muestra el diagrama de secuencias que corresponde a este caso de uso. 
Al igual que en la figura 20.1, ahora mostramos un cambio de estado. 




Figura 20.2 

El diagrama de 
secuencias para 
“Cambiar una orden”. 




Sondeo del progreso de la orden 

Veamos otro caso de uso antes de terminal - . El caso de uso “Sondear el progreso de la 
orden” consta de los siguientes pasos: 

1. El mesero activa la interfaz en la palmtop para sondear una orden registrada. 

2. La interfaz le muestra al mesero una lista de las ordenes que tiene registradas en la 
cocina. 

3. El mesero elige la orden que desea sondear. 

4. El sistema transmite un mensaje de sondeo a la PC de la cocina. 

5. La PC de la cocina recibe el mensaje. 

6. El chef selecciona la orden de la cual se quiere conocer su avance. 

7. El chef teclea un tiempo estimado para completar la orden. 

8. El sistema transmite el tiempo estimado a la palmtop del mesero. 

Para continuar con las modificaciones que hemos hecho, posiblemente queramos cambiar 
el paso 5 a “El mensaje llega a la interfaz del cocinero en la PC de la cocina”. Tambien 
podrfamos hacer una entrevista a un chef o dos para preguntarles cdmo calculan el tiempo 
estimado del paso 7. Quiza pudieramos desarrollar un paquete de software que ayudara 
con ello. 

La figura 20.3 hace los honores a este caso de uso. 








Figura 20.3 
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Implicaciones 

A1 ver todos los resultados obtenidos hasta ahora, los senores LaHudra, Nar y Goniff 
estan euforicos. 

“Esto cambiara todo el entomo del negocio de los restaurantes”, dijo Nar. 

“Se que hemos logrado algo”, dijo LaHudra, “pero, <,que quieres decir con ‘cambiar todo 
el entomo del negocio de los restaurantes’?” 

“Si, £que quisiste decir?”, pregunto Goniff. 

“Bueno, si lo analizan”, respondio Nar, “todo el trabajo de un mesero cambiara, igual 
que el del chef. Los meseros no tendran que corner de aqui para alia como ahora lo 
hacen. Siempre estaran al alcance de los clientes dado que siempre se encontraran en sus 
areas de servicio designadas. Iran a la cocina y al bar solo cuando tengan que hacerlo. 
Mediante sus palmtops, se convertiran en supervisors del proceso de preparacion de las 
ordenes y administradores de sus areas. Seran mas parecidos a salvavidas que a meseros 
tradicionales. De hecho, podran sentarse ocasionalmente mientras se encuentren en sus 
areas, dado que el ‘trabajo’ ya no involucrara andar a las cameras de forma despiadada.” 



que con los chefs?” 






“Tambien seran mas admini strati vos. Utilizaran sus equipos de computo para asignar 
ordenes a sus asistentes, y coordinaran lo que proceda en una cocina. Esto sera estu- 
pendo para grandes cocinas y restaurantes, ahora que lo que hacemos es mover infor- 
mation y no a la gente.” 

“Hum... Suena bien”, dijo LaHudra. “Aparentemente, cuanta mas informacion muevas, 
moveras menos a la gente y lograras mas. No esta mal ” 

“No del todo”, dijo Goniff, ya maquinando la siguiente expansion del negocio. 



Resumen 

Luego del analisis del caso de uso, un equipo de desarrollo volvio su atencion a los com- 
ponentes del sistema que sugirieron los casos de uso. ^Que son? ^Como interactuan? 

Esta hora mostro como responder a estas preguntas dentro del contexto del desarrollo del 
sistema RICO. 

El objetivo de esto es dar informacion a los programadores que les facilite su trabajo. 

Los resultados de este analisis deberan facilitar a los programadores la codification de los 
objetos del sistema y la forma en que se comunican entre si. 

Luego de modelar la cooperacion entre componentes, el sistema ya esta mas cercano a 
convertirse en realidad. Conforme modele la cooperacion entre los componentes, podrfa 
encontrarse con que sera adecuado modificar los casos de uso. 

Preguntas y respuestas 

P Ha mostrado diversas modificaciones a los casos de uso. <,En realidad asi 
ocurre en un proyecto? 

R Indudablemente que si. Ciertamente, los ejemplos podrfan parecer algo amanados; 
por ejemplo: en realidad posiblemente podriamos haber sabido de la base de datos 
en el primer caso de uso antes de llegar hasta este punto. Sin embargo, la meta 
es mostrarle que conforme se desarrolle nuestra nocion, el modelo tambien se 
desarrollara. 

P ^Por que podria ser que los casos de uso originales no capturaran todos los 
aspectos en primera instancia? 

R Porque reflejan los resultados de las sesiones JAD con los usuarios del sistema, no 
con los desarrolladores de sistemas. Vera que todas las adiciones y cambios estaban 
relacionados con el sistema, no con el negocio. Una vez que acabe las sesiones con 
los usuarios potenciales y que tenga la oportunidad de analizar los casos de uso, sera 
comun que salgan a la luz modificaciones como esas. 



Taller 

Aqui sera donde tendra la oportunidad de practicar con el modelado de la cooperation 
entre los componentes de un sistema. Interactue con el Apendice A, “Respuestas a los 
cuestionarios”, para encontrar las respuestas. Tal vez necesite utilizar los componentes 
listados en esta hora para que le ayuden a continuar por encima y mas alia de los ejerci- 
cios listados y hacer otros diagramas de secuencias y colaboraciones. 

Cuestionario 

1. ^,Como representarfa a un objeto que se genera durante el curso de un diagrama de 
secuencias? 

2. ^Como se representa el tiempo en un diagrama de secuencias? 

3. ^Que es la “linea de vida”? 

4. En un diagrama de secuencias, ^como muestra una “activation” y que es lo que 
representa? 

Ejercicios 

1 . Desarrolle un diagrama de colaboraciones equivalente al de secuencias para el caso 
de uso del Mesero “Tomar una orden”. 

2. Cree un diagrama de secuencias para el caso de uso “Tomar una orden de bebida”. 

3. Seleccione al menos un caso de uso del paquete Chef y desarrolle un diagrama de 
secuencias. Utilice la lista de componentes mencionados en esta hora. ^Se necesi- 
tan algunos otros? 

4. Valgase de su imagination con esta: Los casos de uso del paquete Encargado Del 
Guardarropa parecen ser muy sencillos. ^Podna adomar a cada uno mediante la 
adicion de uno o dos pasos? ^Podrian ayudar algunos otros componentes adi- 
cionales? Dibuje un diagrama de secuencias para uno de estos casos de uso. 

5. Continue con su proyecto Biblioteca para listar las partes funcionales de su sistema 
y agregar la colaboracion entre objetos. Genere los diagramas de secuencias para 
los casos de uso resultantes, una vez que haya hecho las modificaciones pertinentes 
a cada caso de uso. 




Hora 2 1 

Diseno del aspecto, 
sensation y distribution 

Ahora nos centraremos en dos importantes aspectos del diseno de sistemas: 
la interfaz del usuario y la distribucion del sistema. 

En esta hora se trataran los siguientes temas: 

• Algunos principios generales del diseno de interfaces graficas 

• La sesion JAD de la GUI 

• De los casos de uso a las interfaces de usuario 

• Diagramas UML para el diseno de la GUI 

• Esbozos de la distribucion del sistema 

Ya ha cumplido con exito gran parte del analisis conducido por casos de 
uso. En esta hora, vera dos importantes aspectos del diseno de sistemas. 
Ambos pueden, a final de cuentas, orientarse a casos de uso, y son muy 
importantes para el producto final. Las GUI (interfaces grdficas de usuario) 
determinan que tan practico es un sistema. La distribucion convierte a la 
arquitectura ffsica planeada del sistema en una realidad. 



Algunos principios generales en el diseno 
de las GUI 

El diseno de las GUI, que conjuga al arte y la ciencia, dibuja, bajo la vision del artista 
grafico, las conclusiones del investigador de factores humanos y las intuiciones del 
usuario potencial. Luego de mucha experiencia con interfaces WIMP (Ventanas, Iconos, 
Menus y Dispositivos apuntadores), han salido a la luz diversos principios generales. He 
aquf los principales: 

1 . Entienda lo que el usuario tiene que hacer. Por lo general, los disenadores de inter- 
faces realizan un analisis de tareas para comprender la naturaleza del trabajo del 
usuario. Nuestro analisis de casos de uso corresponde mas o menos a esto. 

2. Haga que el usuario sienta que tiene el control de la interaction. Siempre incluya la 
posibilidad de que el usuario cancele una accion luego que la haya iniciado. 

3. De al usuario diversas formas de realizar cada accion relacionada con la interfaz (como 
el cierre de una ventana o archivo) y disculpe con elegancia los errores del usuario. 

4. Dadas nuestras influences culturales, nuestros ojos se dirigen a la esquina superior 
izquierda de la pantalla. Coloque la information de mayor prioridad alii. 

5. Apro veche las relaciones de espacio. Los componentes de la pantalla que esten rela- 
cionados deberan aparecer uno junto de otro, quiza con un marco que los bordee. 

6. Destaque la legibilidad y la comprension (jpalabras con las que tenemos que 
vivir!). Utilice la voz activa para comunicar ideas y conceptos. 

7. Aunque tal vez tenga la capacidad de incluir miles de colores en la pantalla, 
restrinja los que vaya a utilizar. De hecho, haga una fuerte limitation de ellos. 
Demasiados colores distraeran al usuario de la tarea por realizar. Por cierto, se 
recomienda dar al usuario la option de modificar los colores. 

8. Si piensa en utilizar colores para indicar algo, recuerde que no siempre sera facil 
para el usuario asociar un color con un significado. A su vez, tenga en cuenta que 
ciertos usuarios (cerca del 10% de los adultos masculinos) sufren de daltonismo, y 
se les podrfa dificultar distinguir a un color de otro. 

9. Como con el color, restrinja el uso de fuentes. Evite las fuentes cursivas y oma- 
mentales. “Haettenschweiler” es un nombre de fuente que puede ser divertido pro- 
nunciar, pero que no fomenta una facilidad de uso. 

10. Intente mantener, tanto como sea posible, los componentes (como los botones y 
cuadros de lista) del mismo tamano. Si utiliza componentes de tamanos dispares, 
multiples colores y fuentes, creara una terrible interfaz que los especialistas en el 
area conocen como un diseno de “pantalon de payaso”. 

11. Alinee los componentes y campos de datos a la izquierda: alineelos de acuerdo con 
sus bordes izquierdos. Esto reduce los movimientos oculares cuando el usuario 
tiene que revisar la pantalla. 




12. Cuando el usuario tiene que leer y procesar information y luego hacer clic en un 
boton, coloque los botones en una columna a la derecha de la information, o en 
una fila debajo y a la derecha de la misma. Esto es conveniente debido a la tenden- 
cia natural (o cultural) de leer de izquierda a derecha. Si uno de los botones es el 
predeterminado, destaquelo y coloquelo como el primero en el conjunto. 

Esta docena de principios no son los unicos, pero nos dan una idea de lo que esta involu- 
crado en el diseno de una GUI. El reto es comunicar la information adecuada en un con- 
texto visual elemental, directo e intuitivo. 



Para ver mayor informacion respecto al diseno de interfaces, en especial las 
que estan relacionadas con Windows, visite http : / /msdn . microsof t . com/UI. 
En esa misma pagina encontrara informacion para el diseno de paginas Web 
o puede visitar www.useit.com. En ambos casos, la informacion se encuentra 
en ingles. 



La figura 21.1 le muestra lo que ocurre cuando pone en action algunos de estos princi- 
pios y la figura 21.2 le muestra lo que sucede cuando no lo hace. 



Figura 21.1 

Aplicacion de los prin- 
cipios para el diseno 
de GUI. 
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Figura 21.2 

El resultado de no 
aplicar los principios 
para el diseno de GUI. 







La sesion JAD para la GUI 

Aunque la sesion JAD no tendra una conexion directa con el UML, es buena idea hablar 
de la forma en que los usuarios potenciales determinan a la GUI. Nuevamente, se 
realizara una sesion para el Desarrollo conjunto de aplicaciones (JAD). 

Para esta sesion reunira a los usuarios potenciales del sistema. En el caso de RICO, reuni- 
remos a los meseros, chefs, asistentes de los meseros, asistentes de los chefs, mozos de 
piso y a los encargados del guardarropa. Los integrantes del equipo de desarrollo que 
estaran presentes seran los programadores, analistas, modeladores y un moderador. El obje- 
tivo serd comprender las necesidades de los usuarios e implementar una interfaz de acuerdo 
con sus ideas (una interfaz que integre sutilmente al sistema con los procesos del negocio). 
La antigua manera de desarrollar un sistema (por ejemplo, escribir un programa desde sus 
inicios, moldear el comportamiento del usuario para que puedan interactuar con el y modi- 
ficar los procesos del negocio para que se adapten a el) ya es obsoleta. 

Para mantener la eficiencia de la sesion, programara a los usuarios en grupos de acuerdo 
con el rol que desempenen. Planeara la cantidad de tiempo que se llevard cada sesion de 
acuerdo con la cantidad de casos de usos en el paquete de cada rol. Esto es solo un vago 
lineamiento, claro, ya que algunos casos de uso son mas complejos que otros. Recuerde, a 
su vez, que podrfan aparecer nuevos casos de uso al disenar la GUI. 

La participation de los usuarios en la sesion es un asunto que envuelve a dos partes. En la 
primera se obtendran las pantallas de la interfaz del usuario. En la segunda se aprobaran 
los prototipos generados por el equipo de desarrollo. 

<rDe que forma los usuarios obtendran las pantallas? El moderador sugiere un caso de 
uso con el cual empezar, y los usuarios debatiran las formas de implementarlo mediante 
el sistema. Cuando esten listos para empezar a hablar al nivel de una pantalla especifica, 
los usuarios trabajaran con prototipos en papel. El moderador proporciona una gran hoja 
de papel para rotafolios de manera horizontal para representar la pantalla. Las notas 
autoadheribles representaran a los componentes de la GUI (por ejemplo: menus contex- 
tual, botones, cuadros combinados, cuadros de lista). La tarea de los usuarios sera tra- 
bajar en conjunto para colocar los componentes de manera adecuada. 

Cuando lleguen a un acuerdo en los componentes que deban estar en una pantalla y su 
disposition, los miembros del equipo de desarrollo generar&n pantallas de prototipo. 
Conforme hagan su trabajo, iran utilizando los principios adecuados del diseno de GUIs 
que se indicaron en la section anterior. Luego, presentaran tales pantallas en computado- 
ras y los usuarios les haran las modificaciones necesarias. 

La meta de todo esto, claro esta, es que los usuarios (y no los desarrolladores) conduzcan 
el proceso tanto como se pueda. Asi, el sistema funcionara de manera optima en las 
actividades reales y diarias del negocio. 




De los casos de uso a las interfaces 
de usuario 

Los casos de uso describen la forma en que se utiliza el sistema. Por ello, la interfaz del 
usuario tiene que servir como medio para implementar los casos de uso. 

Imagine un diagrama de secuencias de un caso de uso como una visidn de un caso de 
uso. Si pudieramos “girar” tal vision en tres dimensiones, para que la parte del extremo 
izquierdo del diagrama de secuencias se desprendiera de la pagina y quedara frente a 
nosotros, verfamos la interfaz que llevarfa al usuario a la secuencia (vea la figura 21.3). 



Figura 21.3 

El supuesto “giro” 
del diagrama de se- 
cuencias nos pone de 
manifesto la interfaz 
del usuario . 




Examinemos los casos de uso del paquete Mesero y veamos c6mo encajan en la interfaz 
de RICO. Nuevamente, aquf estan tales casos de uso: 

• Tomar una orden 

• Transmitir la orden a la cocina 

• Cambiar una orden 

• Recibir una notification de la cocina 

• Sondear el progreso de la orden 

• Notificar al chef del progreso de los clientes en sus alimentos 

• Totalizar una cuenta 

• Imprimir una cuenta 

• Llamar a un asistente 




• Llamar a un mozo de piso 

• Tomar una orden de bebida 

• Transmitir una orden de bebida al bar 

• Obtener un acuse de recibo 

• Recibir una notificacion del bar 

La interfaz del Mesero tiene que incluir a todos estos casos de uso. 

Una forma de empezar es dividir al conjunto de casos de uso en grupos. Con tres de ellos 
sera suficiente. Uno englobara a las ordenes (“Tomar una orden”, “Cambiar una orden”, 
“Sondear el progreso de la orden”, ‘Tomar una orden de bebida”). Otro grupo englobara a 
las cuentas (“Totalizar una cuenta”, Tmprimir una cuenta”). El tercer grupo englobara al 
envio y recepcion de los mensajes (“Notificar al chef del progreso de los clientes en sus ali- 
mentos”, “Llamar a un asistente”, “Llamar a un mozo de piso”, “Transmitir una orden de 
bebida al bar”, “Obtener un acuse de recibo”, “Recibir una notificacion del bar”). 

Tal vez necesitemos empezar con una pantalla principal que llevarfa al mesero por diver- 
sas pantallas hacia todos los demas grupos de casos de uso. Necesitamos tener la posibi- 
lidad de navegar de un grupo a cualquier otro. Dentro de un grupo, necesitamos navegar 
a cualquier caso de uso dentro del grupo. La figura 21.4 muestra una idea inicial de la 
pantalla principal. Esto tendra que encontrarse en una palmtop, por lo que tal vez sea 
necesario ajustar su tamano de alguna forma. 




Nuestra sesion JAD podrfa llegar a convenir que la navegacion dentro de un grupo se 
realizarfa mediante botones localizados a la derecha de la pantalla, en tanto que la nave- 
gacion entre grupos se realizarfa con botones en la parte inferior de la pantalla. La 
figura 21.5 le muestra una idea basica de una de las interfaces del Mesero: la de los 
casos de uso relacionados con las ordenes. 

Esta pantalla se abre en el modo Ordenes. El gran cuadro bianco se desplazara con una 
copia del menu con casillas de verification que el mesero seleccionard para indicar las 
selecciones del cliente (cuando veamos la interfaz, tendremos un especial cuidado al uti- 
lizar la palabra “menu”). Al hacer clic en Aceptar se genera la orden y se envia a la PC 
de la cocina. Al hacer clic en un boton de la derecha se obtendran sus caracterfsticas 
asociadas. 




Figura 21.5 



Pantalla para los casos 
de uso relacionados 
con las ordenes. 



Vista de Ordenes 







Cuando se haga clic en los botones de la fila inferior se obtendra otro grupo de capaci- 
dades. Por ejemplo, el boton Mensaje traera la pantalla de la figura 21.6. Por cierto la 
interfaz de usuario no debe ser solo visual. Esta interfaz tiene que incorporar algun ele- 
mento audible para notificar a un mesero que le ha llegado un mensaje. Asf, hara clic en 
el boton Leer para que se le presente una lista desplegable de mensajes. 

Figura 21.6 

Pantalla para los casos 
de uso relacionados 
con los mensajes. 



Diagramas UML para el diserio de la GUI 

El UML no hace recomendaciones especificas respecto a los diagramas para disenos 
GUI. No obstante, en una hora anterior indicamos una posibilidad: recuerde que en la 
hora 8, “Diagramas de estados”, presente un ejemplo que trataba de los cambios de 
estado en una GUI. Aunque tal ejemplo profundizo en la funcionalidad de una GUI mas 
de lo que deberfamos en este punto, sugiere que los diagramas de estados son utiles 
cuando se trata de interfaces de usuario. 





En la hora 24, "El futuro del UML", presentaremos algunas ideas de como 
extender el UML para modelar las GUIs. 




Deberia usar un diagrama de estados para mostrar el flujo de una interfaz de usuario. La 
figura 21.7 le muestra como las pantallas de alto nivel en la interfaz del Mesero se 
conectan entre si. 



Figura 21.7 

Un diagrama de esta- 
dos para el flujo de 
pantalla de alto nivel 
en la interfaz del 
Mesero . 




Como una pantalla en particular consta de varios componentes, un diagrama de clases 
para un objeto compuesto es adecuado para modelar una pantalla. La figura 21.8 muestra 
un diagrama para un objeto compuesto que corresponde con la pantalla de la figura 21.5. 



Figura 21.8 

Un diagrama compues- 
to que corresponde 
con la pantalla de la 
figura 27.5. 




Esbozos de la distribucion del sistema 

Luego de que el segmento de analisis GRAPPLE ha producido el concepto general del 
sistema RICO, un ingeniero de sistemas empezara a pensar como debera lucir la arqui- 
tectura fisica. Empezara a considerar las altemativas en topologfas de red y la forma 
de implementarlas de manera inalambrica, y comenzara a resolver que componentes de 
software perteneceran a determinados nodos en la red. Este segmento de diseno no tiene 
que esperar a que el analisis se haya completado. Sus acciones pueden proceder de forma 
paralela con las de los segmentos GRAPPLE, como con el diseno de la GUI. 

La meta se centra en que el administrador del proyecto sondee todas las acciones en 
todos los segmentos. 





















La red 

A1 recordar los distintos tipos de LAN disponibles (vea la hora 13, “Diagramas de dis- 
tribution”), el ingeniero del sistema cuenta con diversas opciones. El objetivo es elegir 
aquel que se integre mejor con la conectividad inalambrica en las palmtops. 

Para comprender algunas de las decisiones que el ingeniero del sistema tiene que tomar, 
vamos a profundizar un poco en las redes LAN inalambricas (WLANs). Es frecuente el 
caso de que un transceptor de radio conocido como punto de acceso se coloque en un 
lugar fijo y se conecte a una LAN (por algun medio alambrico estandar). El punto de 
acceso recibe los mensajes de, y transmite los mensajes a, los dispositivos inalambricos, 
y cambia los mensajes recibidos a una forma que la red alambrica entienda. Varios pun- 
tos de acceso aumentaran el rango de la WLAN y la cantidad de usuarios que podran 
acceder a ella. 

^De que manera los usuarios accederian a la WLAN? En RICO, haran la conexidn me- 
diante adaptadores LAN inalambricos integrados con sus palmtops. No importa cuantos 
puntos de acceso se incorporen en la red, cada palmtop se asocia con solo un punto de 
acceso y su area de cobertura, lo que se conoce como microcelda (que es similar a una 
celda que funciona en los telefonos celulares). 

El ingeniero del sistema tendra que decidir cuantos puntos de acceso debera tener el 
restaurante, que tipo de adaptador inalambrico LAN integrara a las palmtops, y el tipo y 
disposition de la red alambrica. 




Si algo de esto le ha interesado para su WLAN, visite www.wlana.com, el sitio 
Web de la Alianza inalambrica LAN (WLANA). WLANA es un consorcio de 
corporativos que comercializan componentes para redes WLAN. 



Vamos a suponer que el ingeniero del sistema decide utilizar una red thin ethemet para la 
LAN (vea la hora 13). 

Los nodos y el diagrama de distribution 

Ya enumeramos los nodos en nuestro sistema. Los meseros, asistentes de meseros y 
mozos de piso tendran palmtops. La cocina, guardarropa y bar tendran computadoras de 
escritorio. Cada computadora se conectara a una impresora. Ademas, cada area de servi- 
cio tendra una computadora de escritorio conectada a una impresora para que pueda 
imprimir cuentas y obtenerlas sin caminar demasiado (un servidor de impresion, si se 
puede llamar asf). 




No obstante, en este punto veremos un ejemplo primordial del porque es mejor empezar 
a pensar en las caracteristicas de distribucion desde el principio. Conforme se avanza, el 
ingeniero del sistema y el equipo de desarrollo tendran que tomar una decision de nego- 
cios: las palmtops requieren adaptadores LAN inalambricos, que podrfan ser muy cos- 
tosos, y el software asociado podria estar fuera de las necesidades iniciales. Una posibilidad 
potencialmente menos costosa es la de cambiar los dispositivos moviles de palmtops a 
otras conocidas como Handheld que ejecuten Windows CE y utilicen una tarjeta PC para 
conectarse de manera inalambrica a la LAN. Una caracteristica importante de esta alter- 
nativa es que los programadores pueden utilizar herramientas de desarrollo ya conocidas 
para crear el software y llevarlo a las computadoras moviles. 

^Por que no utilizar una palmtop con Windows CE? Cuando escribi estas lfneas, los dis- 
positivos Palmtop con Windows CE no tenian ranuras para tarjetas PC, y la unica tarjeta 
PC WLAN para Windows CE era la Proxim RANGELAN2. Conclusion: resuelva estos 
detalles en los procesos iniciales del proyecto. 

En cualquier caso, asumamos que el equipo de desarrollo y los usuarios deciden utilizar 
la solucion Windows CE/Proxim, con la idea de que el desarrollo sera mas eficiente y 
economico si los desarrolladores pueden aprovechar sus herramientas de desarrollo para 
crear el codigo necesario. Como comentario al margen, de acuerdo con la velocidad a la 
que avanzan las cosas, podria aparecer en cualquier momento un nuevo dispositivo 
Palmtop con Windows CE y una ranura para tarjetas PC. 

Esta lfnea de razonamiento orienta al ingeniero del sistema hacia una solucion Proxim 
para un punto de acceso a la LAN; al igual que la tarjeta PC, tambien se llama RANGE- 
LAN2. 

Para ilustrar la distribucion, el ingeniero del sistema genera el diagrama de distribucion 
que se muestra en la figura 21.9. 




Figura 21.9 



Diagrama de distribu- 
tion para RICO. 
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Siguientes pasos 

El equipo de desarrollo ha ido de los casos de usos a las interfaces y a las WLANs. ^Que 
sigue? 

Para empezar, los analistas pondran en orden al modelo. Veran el diccionario de modelos 
y pondran en orden cualquier ambigtiedad. Se aseguraran de que toda la terminologia sea 
utilizada de manera consistente en todos los diagramas y que los problemas con terminos 

































como “menu” no propendan a confusiones. Cuando se completen todas las partes del 
analisis y diseno de GRAPPLE, el equipo compilara los resultados en un documento de 
diseno y enviara copias al cliente y a los programadores. 

A los programadores o desarrolladores es a quienes corresponde convertir el diseno en 
codigo (la parte de la codification va mas alia de los alcances de este libro). 

El codigo sera probado, vuelto a escribir de acuerdo con los resultados de las pruebas, y 
vuelto a probar (proceso que continuara una y otra vez hasta que el codigo pase todas las 
pruebas). El analisis de los casos de uso conforma los fundamentos de las pruebas. 

Los especialistas en la documentacion empezaran a crear la informacion del sistema, y 
crear£n tambien los materiales de entrenamiento. Un buen proyecto para la creation de la 
documentacion debena proceder como uno para el desarrollo de un sistema, con una 
cuidadosa planeacion, analisis y pruebas, y debera comenzar en las primeras instancias 
del proceso de desarrollo. 

Con un documento de diseno bien organizado e informativo y con un analisis y diseno 
solidos, los siguientes pasos deberian proceder sin problemas durante todo el proceso de 
desarrollo. 

La idea principal es enfocar los esfuerzos primordialmente en el analisis y diseno para 
que la implementation tenga muy pocos traspies y que el proyecto de por resultado un 
sistema que cumpla por completo con las necesidades del cliente. 

...Y ahora, unas palabras de nuestros 
patrocinadores 

Los senores LaHudra, Nar y Goniff no podnan estar mas emocionados por la forma en 
que ha transcurrido el proyecto de desarrollo. El equipo de desarrollo los ha mantenido 
informados del proceso y les ha dado disenos basados en UML que les muestran el punto 
en que se encuentra el proyecto. Incluso estan satisfechos por la forma en que el equipo 
soluciono el gran problema de distribution respecto a los dispositivos moviles. 

Todo el esfuerzo ha despertado sus imaginaciones y los ha impulsado a buscar nuevas for- 
mas de utilizar la tecnologia (tanto dentro como fuera del mundo restaurantero). Han 
caido en la cuenta que la mayorfa de los procesos de negocios involucran la transmision 
de la informacion. El grado en que la tecnologia acelera tal transmision, representa una 
enorme ventaja competitiva. 

Mejorar el trabajo de la fuerza de ventas 

Fuera del mundo restaurantero, los tres empresarios ven el potencial de volver a utilizar 
las ideas de la LAN inalambrica para una fuerza de ventas movil dentro de un enorme 
area de trabajo. El volverlas a emplear no deberfa ser dificil, ya que toda la informacion 
de los modelos esta intacta. 




Una aplicacion de esta idea podria ser en las enormes tiendas departamentales o de 
autoservicio. Los vendedores de piso de dichas tiendas podrfan beneficiarse de un dis- 
positivo de mano que acceda a la information de los productos mediante una LAN 
inalambrica. Un sistema como este podria ayudar al vendedor a responder preguntas 
respecto al lugar donde se encuentra el producto en la tienda, si hay en existencia y como 
se podria utilizar. 

Esto tiene algunas implicaciones intrigantes tanto para el vendedor como para el cliente. 
Los clientes estarian seguros que siempre obtendran la informacion mas reciente y con- 
cisa del vendedor. Un nuevo vendedor entrenado sobre como utilizar el sistema podria, 
con rapidez, empezar a trabajar aunque tu viera una minima capacitacidn sobre el 
almacen. 

LaHudra, Nar y Goniff pronto invadiran el mundo de las mejoras al hogar. 

Expansiones en el mundo restaurantero 

Esta idea de la fuerza de ventas movil no es suficiente para LaHudra, Nar y Goniff. No 
quieren hacer nada que no incluya a la tecnologfa para revolucionar los negocios restau- 
ranteros. Creen que >odrfan crear restaurantes basados en RICO en las principales ciu- 
dades del mundo. Creen que la tecnologfa simplificara la sensation de comer fuera de 
casa y lo hara mas conveniente para que todos salgan a hacerlo. 

Goniff, como siempre en busca de nuevas formas de ganar dinero, tiene un buen rato 
pensado en esto (j al menos desde que finalizd la hora 20!). 

“Amigos” les dijo a sus socios, “si construimos restaurantes en todas las ciudades princi- 
pales, podriamos llevar la tecnologfa a un siguiente paso y transmitir la informacion por 
doquier.” 

“^Como?” pregunto Nar, que siempre ha sido algo torpe. 

“Piensenlo. Si nos intemacionalizamos, podriamos entrar en la Web y...” 

LaHudra interrumpe: “Un momento. Ya estamos en la Web. Hay muchos que visitan 
www.lahudranargoniff.com, no?” 

“Dejame terminar, LaHudra. Podriamos utilizar la Web para que la gente ‘vaya’ a todos 
estos restaurantes. Utilizarfamos la Web para darles un emparedado gratuito ” 

“jQue?” preguntaron Nar y LaHudra al unfsono y con incredulidad. 

“Vamos a ver. Orientamos una pagina de nuestro sitio Web a nuestra division de restau- 
rantes. Alguien entra a la pagina, da su nombre y otra informacion, y se le pide que elija 
el emparedado que desee. Si nuestra base de datos muestra que el visitante no ha hecho 
esto con anterioridad, se le presentarfa otra pagina donde podra imprimir un cupon para 
un emparedado. Llevara el cupon al restaurante mas cercano. Obtendra el emparedado, lo 
comera, le gustara y regresara como un cliente normal ” 



“Si, pero la Web puede verse en cualquier parte”, dijo Nar, “Supon que alguien no vive 
cerca de uno de nuestros restaurantes y, de todas maneras, desea el emparedado ” 

“iAguarden! \ Ya se!’\ dijo LaHudra. “Pueden utilizar su tarjeta de credito para pagar un 
cargo nominal por envfo en el sitio Web, y nuestro restaurante mas cercano se lo enviara 
a su hogar en un frfo y economico contenedor. Podran colocar el emparedado en su 
homo de microondas y calentarlo. Asi, podran comer un producto de LaHudra, Nar y 
Goniff donde esten. Luego, cuando viajen a una ciudad donde haya uno de nuestros 
restaurantes, querran comer alii ” 

“Por cierto, £para que seria el resto de la informacion que ellos capturen antes de 
imprimir el cupon?”, pregunto Nar. 

“Te lo dire,” dijo Goniff. “Utilizaremos esta indagacion para enviarles por correo elec- 
trdnico informacion promocional de nuestros demas negocios, de acuerdo con su 
demograffa (siempre y cuando indiquen que quieren recibirla). 

Donde esta el equipo de desarrollo? Tenemos mucho trabajo que hacer” 

Resumen 

Cuando su proyecto se encuentre en el segmento de diseiio, habra dos elementos por 
enfocar que seran la interfaz del usuario y la distribucion del sistema. Ambos son final- 
mente conducidos por los casos de uso y de extrema importancia. 

El diseno de la interfaz del usuario depende de una vision artistica y de una investigation 
cientifica. Varios de los principios del diseno de la interfaz han salido a la luz luego de 
anos de trabajo con interfaces WIMP Esta hora le mostro algunos de ellos. Tengalos en 
cuenta cuando su equipo de desarrollo disene GUIs. 

Los casos de uso conducen el diseno de la interfaz del usuario. El sistema tiene que per- 
mitir al usuario completar cada caso de uso, y la interfaz es la puerta de acceso hacia 
cada uno de ellos. 

De forma simultanea con varios de los procesos del proyecto, el ingeniero de sistemas 
del equipo se orientara a la arquitectura fisica. La arquitectura esta conducida por los 
casos de uso dado que el uso del sistema finalmente determina la naturaleza fisica y la 
disposition del mismo. El ingeniero de sistema otorga un diagrama de distribucion UML 
que muestra los nodos, los componentes de software que haya en cada nodo y las co- 
nexiones entre nodos. Aunque los detalles de la distribucion aparecen en las etapas avan- 
zadas del proceso GRAPPLE, no hay razon para no empezar a pensar en ellos en etapas 
previas. Como se mostro en esta hora, pueden aparecer detalles fundamentales que nece- 
sitaran ser resueltos. 



Luego que el sistema ha sido modelado, la informacion del modelado puede volver a uti- 
lizarse en diversos contextos. El modelo puede impulsar miles de ideas nuevas para 
negocios. 



Preguntas y respuestas 

P Una vez que los usuarios hayan generado un prototipo en papel, £en realidad 
sera necesario erear la pantalla y mostrarselas? Despues de todo, ya generaron 
la pantalla en el papel y colocaron adecuadamente los componentes. ^No 
podnan esperar y ver las pantallas en el sistema una vez que este finalizado? 

R Es indudable que tendra que mostrarles a los usuarios una pantalla verdadera (“ver- 
dadera” en el sentido de la computadora). Para empezar, es muy probable que los 
usuarios vean cosas en la pantalla que no vieron en el papel. Otra razon (relacio- 
nada con la primera) es que las dimensiones de las notas autoadheribles solo se 
aproximan a las de los componentes en la pantalla. Colocar las notas autoadheri- 
bles podrfa distorsionar la relacion de espacio entre los componentes de la pantalla. 
La pantalla podrfa lucir un tanto distinta al prototipo en papel. A su vez, las cap- 
turas de la pantalla se convertiran en partes muy valiosas para su documento de 
diseno. 

P Se que esto no esta directamente relacionado con el UML, pero uno de los 
principios de la GUI que menciono fue dar al usuario diversos medios para 
realizar las acciones relacionadas con la interfaz. ^Por que esto es importante? 

R Lo es porque no podra predecir todos los contextos en donde un usuario realizara 
una accion. En ocasiones el usuario utilizara una aplicacion que utiliza mucho el 
teclado, y una combinacion de teclazos sera mas adecuada que un clic con el raton. 
En ocasiones el usuario utilizara mucho el raton, y un clic sera mas adecuado. Dar 
ambos medios para realizar lo mismo hace que la interaccion sea mas facil para el 
usuario. 

P Y hablando de preguntas que no se relacionan con el UML, quisiera saber el 
porque del principio de la “voz activa” en la GUI. 

R Los estudios demuestran que las personas comprenden mejor la voz activa que la 
pasiva. A su vez, la voz activa requiere, por lo general, menos palabras y, con ello, 
ocupara menos del precioso espacio de la pantalla que la voz pasiva. Los usuarios 
(asf como los editores y jefes de redaction) aprecian si sus instrucciones dicen: 
“Haga clic en el boton Siguiente para continuar” en lugar de “El boton Siguiente 
deberfa ser oprimido por usted para que continue el proceso”. 



Taller 

Este taller verifica su conocimiento de las cuestiones relacionadas con el diseno del 
aspecto y sensacidn de un sistema, y para orientarse a la arquitectura ffsica correspon- 
diente. Disene bien sus respuestas y, luego, vaya al Apendice A, “Respuestas a los cues- 
tionarios” para verificarlas. 

Cuestionario 

1. ^Que es un analisis de tareas? 

2. ^Cual analisis de los que ya hemos hecho es un vago equivalente de un analisis de 
tareas? 

3. ^Que se entiende por un diseno de tipo “pantalon de payaso”? 

4. De tres razones para restringir el uso del color en una GUI. 

Ejercicios 

1. Utilice un diagrama de estados UML para modelar la interfaz del usuario del chef. 

2. Utilice papel y Mpiz para disenar al menos una de las pantallas de la interfaz del 
usuario del chef. Empiece por agrupar los casos de uso y, luego, cfnase a las con- 
venciones de la sesion JAD. Si puede utilizar Microsoft Visual Basic, o alguna otra 
herramienta para el diseno visual de pantallas, intente utilizarla para completar este 
ejercicio. 

3. Nuevamente, continue con el analisis de las tareas que haya obtenido en su 
proyecto de la Biblioteca. No olvide hacer un analisis de la distribution. 




Hora 

Nocion de los patrones 
de diseno 

Ahora que ha comprendido los fundamentos del UML y ha visto c6mo uti- 
lizarlo en el contexto de un proyecto de desarrollo, finalizaremos la parte II 
con una semblanza de la aplicacion del UML a un area novedosa: los 
patrones de diseno. 

En esta hora se trataran los siguientes temas: 

• Parametrizacion 

• Patrones de diseno 

• Cadena de responsabilidad 

• Uso de nuestros propios patrones de diseno 

• Ventajas de los patrones de diseno 

En las 21 horas anteriores ha visto muy diversos temas. Desde los diagramas 
de clases hasta los de secuencias, desde los diagramas de estados hasta las 
sesiones JAD, la meta fue prepararlo para aplicar el UML en situaciones que 
ocurren frecuentemente en el mundo real. 




Ahora, cambiaremos nuestro rumbo un poco. En esta hora exploraremos una de las apli- 
caciones del UML que, posiblemente, se haran mas populares. Esta aplicacion, la repre- 
sentation de patrones de diseno, captura la esencia de las soluciones que han funcionado 
una y otra vez en proyectos y situaciones reales. 



Parametrizacion 

En la hora 2, “Orientation a objetos”, mencione que una clase es una plantilla para la ge- 
neration de objetos. Le dije que podia concebir a una clase como un molde de galletas 
generador de nuevos objetos. Un objeto, recordara, es una instancia de una clase. 

Para ayudarle a recordar, veamos de nuevo el ejemplo de nuestra lavadora. La especifi- 
cacion de la clase lavadora (o, para utilizar una notation correcta, la clase Lavadora) 
incluia los atributos marca, modelo, numeroDeSerie y capacidad, y las operaciones 
agregarRopaQ, agregarDetergente y quitarRopa(), con lo que tendriamos una forma de 
generar nuevos objetos provenientes de nuestra clase Lavadora. Cada vez que queramos 
crear un objeto, asignaremos valores a los atributos. 

El propio UML le permite ir un paso mas alia. Le da un mecanismo para crear clases de 
una forma similar a la creation de objetos. Podra establecer una clase de manera que 
cuando asigne valores a un subconjunto de sus atributos habra creado una clase en lugar 
de un objeto. A este tipo de clase se le conoce como clase parametrizada. Su represen- 
tation en el UML aparece en la figura 22. 1 . El cuadro punteado del extremo superior 
derecho contiene los parametros a los que asignara valores para generar la clase. A estos 
se les llaman parametros desvinculados. Cuando les asigne valores, los vinculara con 
ellos. La T del cuadro punteado es un clasificador que indica que la clase es una plantilla 
para crear otras clases. 



Figura 22.1 ”! 

El icono UML para 
una clase parame- 
trizada . 

He aquf un ejemplo. Suponga que establece un SerVivo como clase parametrizada. Los 
parametros desvinculados podrfan ser generos y especies, junto con los atributos estan- 
dar de nombre, estatura y peso, como se muestra en la figura 22.2. 

Si vincula a genero con “homo” y a especie con “sapiens”, creara una clase llamada 
“Humano”. El nombre de la clase se vincula con la T. La figura 22.3 le muestra una 
forma de representar tal vinculacion. Este estilo en particular se conoce como vincu- 
lacion explicita porque muestra de manera explfcita la clase generada en una relation de 
dependencia con la clase parametrizada y le da a la clase generada su propio nombre. 






Figura 22.2 
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estatura: Integer 
peso: Integer 










Figura 22.3 
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de la clase parame- 
trizada SerVivo. 


nombre:String 
estatura: Integer 
peso: Integer 
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«Vincular» 

{Humano, homo, sapiens) 



Humano 



Hay otro tipo de vinculacion que se conoce como vinculacion implfcita. En ella no se 
muestra la relacion de dependencia, y las vinculaciones aparecen en una lista dentro de 
parentesis angulares en el nombre de la clase generada. La figura 22.4 le muestra lo 
anterior. 



Figura 22.4 

Vinculacion implicita 
de la clase parame - 
trizada SerVivo. 
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SerVivo 

nombre:String 
estatura: Integer 
peso: Integer 



SerVivo<Humano,homo,sapiens> 



En cualquier caso, podra asignar valores a nombre, estatura y peso para generar objetos 
en la clase Humano. 




Patrones de disefio 

Es posible expandir la idea de la parametrizacion. Cualquier clasificador UML puede 
ser parametrizado. De hecho, un grupo de clasificadores que colaboren entre si pueden ser 
parametrizados, lo que nos evitara entrar en situaciones desconcertantes. 

Despues de varias decadas de amplio uso, mismo que se incrementa, la orientacion a 
objetos ha otorgado varias soluciones firmes a los problemas recurrentes. Tales solu- 
ciones se conocen como patrones de disefio , y han jugado un importante papel ultima- 
mente. Como los patrones de diseno han traspasado el mundo de la orientacion a objetos, 
son fr'ciles de conceptualizar, diagramar y reutilizar. A1 contar ahora con el UML, tene- 
mos ur lenguaje de modelado comun para explicarlos y diseminarlos. 

El primer libro que popularizo a los patrones de diseno fue “Design Patterns” (Addison- 
Wesley, 1995). nus autores (Erich Gamma, Richard Helm, Ralph Johnson y John 
Vlissides) han sido reconocidos como el “Grupo de los cuatro”. 

Un patron de diseno es basicamente una solucion (un diseno) que surge de la experimen- 
tation practica con varios proyectos, y los equipos de desarrollo han encontrado que se 
puede aplicar en diversos contextos. Cada patron de diseno describe a un conjunto de 
objetos y clases comunicadas. El conjunto se ajusta para resolver un problema de diseno 
en un contexto especifico. 

En su libro, el grupo de los cuatro catalogo y destaco a 23 patrones de diseno funda- 
mentals. Dividieron esos patrones en tres categorias de acuerdo con cada uno de sus 
propositos : (1) Patrones de creacion que atanen al proceso de creacion de objetos, (2) 
Patrones de estructura que se orientan a la composition de clases y objetos, y (3) 
Patrones de comportamiento que especifican la forma en que las clases u objetos interac- 
tuan y distribuyen la responsabilidad. Posteriormente dividieron sus patrones de diseno 
en terminos si se aplican a las clases u objetos. A este criterio lo llamaron ambito , y la 
mayona de los ambitos de los patrones se encuentra al nivel de los objetos. 

Cada patron de diseno tiene cuatro elementos: (1) un nombre que nos permite describir 
un problema de diseno en una palabra o frase, (2) un problema que define cuando aplicar 
el patron, (3) una solucion que ^specifica los elementos que conforman al diseno y como 
colaboran, y (4) las consecuencias de aplicar el patron. 

Ahora veremos esas “situaciones desconcertantes” que indique con anterioridad: dentro 
de un modelo, podemos representar un patron de diseno como una colaboracion parame- 
trizada en el UML. El patron de diseno se expresa de una forma generica, con nombres 
genericos para los colaboradores. El asignar nombres especificos del dominio hace que el 
patron se aplique a un modelo especifico. La colaboracion parametrizada le ayuda a 
visualizar los detalles especificos dentro del contexto del patron. 




Cadena de responsabilidad 

Examinemos un patron de diseno y vera lo que quiero decir. 

La Cadena de responsabilidad es un patron de comportamiento que se aplica a cierta can- 
tidad de dominios. Este patron se encarga de la relacion entre un conjunto de objetos y 
una peticion. Aplicara este patron cuando mas de un objeto pueda manejar una peticion. 
El primer objeto en la cadena obtiene la peticion y la resol vera o se la enviara al siguiente 
objeto de la cadena, hasta que uno de ellos pueda manejarla. El objeto que originalmente 
hizo la peticion no sabe cual de los objetos la manejara. El objeto que al final maneje la 
peticion se conoce como un receptor implfcito . 

Los restaurantes estan establecidos de esta forma, al igual que los distribuidores de 
automoviles cuando financian la adquisicion de automoviles. Por lo general, en un 
restaurante un cliente no envia una peticion directamente a un chef ni sabe que chef 
preparara su platillo. En vez de ello, el cliente le da una orden a un mesero, el mesero se 
la lleva al chef, quien podra cumplir con ella o darsela a uno de sus asistentes (de 
cualquier forma, asi ocurre con los supuestos restaurantes de LaHudra, Nar y Goniff). 
Con un distribuidor de automoviles, el agente de ventas pasa el pedido de prestamo a 
diversas instituciones financieras hasta que alguna decide otorgar el prestamo. 

Las ligas de deportes profesionales implementan este patron cuando un equipo pone 
transferible a un jugador. El equipo con la peor marca tendra una oportunidad de solicitar 
al jugador. Si decide no hacerlo, el equipo con la siguiente peor marca tendrd la oportu- 
nidad, y asi sucesivamente. El equipo que puso transferible al jugador no necesariamente 
sabe que otro equipo se quedara con el (vea el Ejercicio 1 ). 

Ahora que ha visto el patron de diseno Cadena de responsabilidad en algunos contextos, 
ya esta preparado para comprenderlo de manera abstracta. Los participantes en este 
patron seran un Cliente, un Controlador abstracto y Controladores concretos que pro- 
vengan del Controlador abstracto. El Cliente inicia una peticion; si un Controlador (con- 
creto) puede ocuparse de la peticion, asi lo hara; si no, pasara la peticion al siguiente 
Controlador abstracto. La figura 22.5 le muestra la forma en que luce esta estructura. 

La idea de este patron es liberar a un objeto de que tenga que saber que otro objeto 
realizara su peticion. Le da una flexibilidad adicional cuando asigne responsabilidades a 
los objetos. La desventaja es que el patron no garantiza que algun objeto maneje la peti- 
cion. Por ejemplo: ningun equipo de futbol contratana a un jugador que haya sido puesto 
como transferible. 



Figura 22.5 

La estructura del 
patron de diseho 
Cadena de respon- 
sabilidad . 




Observe la asociacion reflexiva en la clase Controlador abstracto. El grupo de los cuatro 
intento mostrar que usted tendra la opcion de que el Controlador implemente un vinculo 
sucesor (en algunos contextos, los objetos saben como encontrar a sus sucesores). He 
decidido representar tal implementation con una clase asociacion como en la figura 22.5, 
para permitir que mas adelante se puedan agregar atributos al sucesor. 

Cadena de responsabilidad: dominio Restaurante 

En el dominio Restaurante, el Controlador abstracto es la clase Empleado, y los 
Controladores concretos son el mesero, el chef y el asistente. El Cliente es, en si, el pro- 
pio cliente, quien podrfa iniciar una petition, como hacer una orden, y no saber quien la 
llevara a cabo. 

Al sustituir los nombres especfficos del dominio de la figura 22.5 nos deja la figura 22.6. 



Figura 22.6 

El patron de diseho 
Cadena de responsa- 
bilidad en el dominio 
del restaurante. 











La figura 22.6, aunque es un util diagrama, no nos muestra la forma en que los nombres 
especificos del dominio encajan en el patron. Para mostrar el contexto, utilizaremos una 
colaboracion parametrizada, como en la figura 22.7. 



Figura 22.7 
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En la figura 22.7, el ovalo punteado representa la colaboracion que hay en el patron de 
diseno, de alii el nombre dentro del ovalo. Los cuadros que lo rodean representan a los 
colaboradores. Las dependencias muestran que la colaboracion depende de los colabo- 
radores. La etiqueta en una dependencia indica el rol que juega el colaborador depen- 
diente dentro del patron. La colaboracion se ha parametrizado con la adicion de los 
nombres de clases especificas del dominio. 

Cadena de responsabilidad: Modelos de eventos 
de los exploradores Web 

Cuando se desarrollan paginas Web interactivas, un disenador debe tomar en cuenta el 
modelo de eventos del explorador que las abrira. En Internet Explorer, puede escribir 
codigo de JavaScript o VBScript para reaccionar a un evento, como el clic en un boton. 
Este codigo, conocido como “controlador de evento”, establece los cambios (en caso de 
haberlos) que habra cuando se haga clic en un boton. 

En un documento HTML, podra dividir una pagina en areas conocidas como DIV, y subdi- 
vide a un DIV en formularios. Puede colocar un boton dentro de un formulario. ^Le suena 
a objeto compuesto? jClaro, porque eso es! Cada elemento es un componente del docu- 
mento, y ciertos componentes son parte de otros. La Gamma lista a los objetos compuestos 
como uno de sus patrones de diseno, y se usa con frecuencia junto con el patron de Cadena 
de responsabilidad. La relation entre componente y objeto compuesto implementa los 
vmculos de los sucesores. Cuando le mostre el diagrama de clases de la Cadena de respon- 
sabilidad, le mencione a modo de aclaracion que en ciertos contextos los objetos saben 
como localizar a sus propios sucesores. Este es uno de esos contextos. 







Cuando se coloca el boton en un formulario dentro de un DIV cuyo documento se abre 
en Internet Explorer, el evento de hacer clic en el iniciara con el boton en si, pasara al 
formulario, luego al DIV y, finalmente, al documento que lo contiene. Cada uno de estos 
elementos puede tener su propio controlador del evento hacer clic en el boton, el cual 
reaccionara ante tal evento. 

Si una secuencia de comandos que se encuentre en el documento establece de forma 
dinamica cual de los controladores de eventos del elemento se ejecuta, la secuencia de 
comandos sera una instancia del patron de diseno de la Cadena de responsabilidad. La 
figura 22.8 le muestra el diagrama de clases, y la 22.9 le muestra la colaboracidn parame- 
trizada para este patron de diseno aplicada al modelo de eventos del Internet Explorer. 
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Netscape Navigator tambien cuenta con un modelo de eventos. Su modelo es, exacta- 
mente, lo opuesto al de Internet Explorer. En Navigator, el element de mayor nivel (el 
documento) primero obtiene el evento y lo pasa hasta que lo lleva al que lo origino. 
^Como cambiarfa al diagrama de clases de la figura 22.8 para modelar al modelo de 
eventos de Navigator? (Vea el Ejercicio 2.) 




Internet Explorer llama a su modelo de eventos burbujeo de eventos . Navi- 
gator lo llama captura de eventos. 



Nuestros propios patrones de diseno 

Aunque el Grupo de los cuatro saltaron a la fama por su catalogo de patrones de diseno, 
no establecieron que sus patrones fueran los unicos posibles. Al contrario, intentaron 
alentar el descubrimiento y uso general y propio de los patrones. 

Para darle una idea de la forma en que surgen tales patrones, recuerde lo que hicimos en 
la hora 1 1, “Diagramas de actividades”. Durante esa hora, vio un ejemplo de como tratar 
con los numeros de Fibonacci y un ejercicio referente a los numeros triangulares. 

^Cuales fueron las caracterfsticas en comun? Cada uno empezo con un valor o conjunto 
de valores iniciales, siguio con una regia para acumular numeros y finalizo con el 
enesimo numero de la serie. 

Llamemos a este patron “Calculadora de series”. Aunque podrfamos implementarlo en 
un objeto, hagamoslo en un conjunto de objetos colaboradores para ilustrar algunos con- 
cepts de los patrones de diseno. 

La Calculadora de series cuenta con tres participantes: Valorlnicial (que puede con- 
tener uno o mas valores), ReglaDeAcumulacion y ValorFinal. La figura 22.10 muestra 
el diagrama de clases de este patron. El valor inicial esta en un atributo llamado 
primero. Si es necesario un segundo valor inicial, como en el caso de los numeros de 
Fibonacci, se especifica en un atributo llamado segundo . En ocasiones, como en el 
caso de los factoriales, el patron necesitara un valor para el termino cero. El algoritmo 
para la ReglaDeAcumulacion se implementa en la operacion acumular(). La cantidad 
de terminos por calcular esta en el enesimo atributo en ReglaDeAcumulacion. 

En la colaboracion, ReglaDeAcumulacion obtiene el (los) valor(es) inicial(es) de 
Valorlnicial, aplica la regia la cantidad de veces indicada y envia el resultado a ValorFinal 
para que sea mostrado. La figura 22.1 1 muestra la interaction. 
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Para aplicar este patron de diseno a la serie de numeros triangulares, adoptaremos 
algunos nombres de la numeracion triangular para las clases y mostraremos la colabo- 
racion parametrizada de la figura 22.12. 



Figura 22.12 

La colaboracion para- 
metrizada para la 
Calculadora de 
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Como buena medida, mostraremos la colaboracion parametrizada para una calculadora 
de factorial en la figura 22.13. 
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Ventajas de los patrones de diseno 

Los patrones de diseno son utiles en diversas maneras. Para empezar, promueven la reuti- 
lizacion. Si ha expresado un diseno bien fundamentado como patron, lo habra hecho sen- 
cillo para usted y otros que con el trabajen nuevamente. A su vez, le dan una forma clara 
y concisa de hablar y pensar respecto a un grupo de clases u objetos que funcionen en 
conjunto para resolver un problema. Esto aumenta la posibilidad de que utilice al patron 
como un componente de un diseno. Finalmente, si utiliza patrones en su diseno, posible- 
mente se le facilitara documentar el sistema que haya generado. 

Resumen 

Una clase parametrizada tiene parametros desvinculados. El vincular a tales parametros 
dara como resultado la creation de una clase. Cualquier clasificador UML podra estar 
parametrizado. Una colaboracion parametrizada sirve como la representation de un 
patron de diseno: una solution que es util en diversos dominios. 

Un patron de diseno, la “Cadena de responsabilidad”, se ocupa de que los objetos pasen 
una petition entre ellos hasta que uno pueda manejarla. Este patron proviene del libro 
mas conocido en patrones de diseno, escrito por un grupo de autores conocidos como “El 
grupo de los cuatro”. 

Nuestros propios patrones de diseno surgen del trabajo que hicimos en la hora 1 1 en los 
diagramas de actividades. Podemos crear un patron de diseno para una calculadora que 
determine el enesimo valor de una serie aritmetica. Los participantes en este patron son 
Valorlnicial, ReglaDeAcumulacion y ValorFinal. 







Los patrones de diseno ofrecen varias ventajas. Permiten que los disenadores vuelvan a 
utilizar con facilidad las soluciones ya probadas, incorporar componentes soiidos en los 
disenos y documentar claramente los sistemas que generen. 



Preguntas y respuestas 

P iQue tan dificil es “descubrir” los patrones de diseno? 

R No es cuestion de dificultad, sino de experiencia. Conforme avance en su carrera 
de analista y disenador, vera que hay ciertas cosas que se repiten una y otra vez 
y despues de un tiempo tratara de aprovechar esas circunstancias regulares. Los 
estudios muestran que los expertos en un dominio en particular piensan en termi- 
nos de patrones y tratan de aplicarlos siempre que pueden. 

P ^Los patrones solo son utiles en el diseno? 

R No. Los patrones pueden surgir en cualquier momento del proceso de desarrollo o 
en cualquier campo de action. El Grupo de los cuatro se inspiro en el trabajo de un 
arquitecto que penso en recurrir a patrones para el diseno de los edificios. 



Taller 

Las preguntas y ejercicios en este taller le llevardn a pensar respecto a algunas caracteris- 
ticas avanzadas del UML. Vaya al Apendice A, “Respuestas a los cuestionarios”, para 
encontrar las respuestas. 

Cuestionario 

1 . iComo representarfa a una clase parametrizada? 

2. ^Que es “vincular” y cuales son los dos tipos de vinculacion? 

3. iQue es un “patron de diseno”? 

4. ^Que es el patron de diseno “Cadena de responsabilidad”? 

Ejercicios 

1. Aplique el diagrama de clases del patron diseno Cadena de responsabilidad al pro- 
ceso de transferencia que se realiza en las ligas deportivas profesionales. 

2. Modifique el diagrama de clases de la figura 22.8 de modo que deje entrever el 
modelo de eventos de Netscape Navigator. Como ya lo indique anteriormente, un 
evento en Navigator se inicia al nivel del documento y pasa por los distintos ele- 
mentos hasta que llega al que lo origino. El elemento originador podrfa localizarse 
a varios niveles por debajo del documento HTML. 
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Modelado de sistemas 
incrustados 

Esta vez vera lo referente a sistemas de computo que no se basan en sis- 
temas de escritorio, laptops o en palmtops. En vez de ello, estaran incrusta- 
dos dentro de aparatos como aviones, trenes y automoviles. 

En esta hora se trataran los siguientes temas: 

• ^Que son los sistemas incrustados? 

• Conceptos de los sistemas incrustados 

• Modelado de un sistema incrustado en el UML 

LaHudra y sus intrepidos socios, Nar y Goniff, han tenido buenas ganancias 
de su Division de Restaurantes LNG. El servicio es tan bueno y las comidas 
tan deliciosas que la gente llega por miles para probarlas dentro de una 
atmosfera de eficiencia y amistad. 



Hay dos problemas que deterioran su otrora buena fortuna. Conforme leen los informes 
mensuales, la terrible tendencia ha continuado. “Miren esto”, dijo Nar dandoles los 
escritos a Goniff y LaHudra. “Estamos haciendo mucho dinero, pero debenamos hacer 
mas. Parece que los meseros estan rompiendo mas losa de la aceptable.” 

“Si, ya lo habia advertido”, dijo Goniff. “Cada vez que rompen un plato lleno de comida, 
el cocinero tiene que preparar otra vez el plato. Y tenemos que pagar el nuevo plato.” 

“,-Realmente importa si algunos de nuestros meseros tienen las manos torpes?”, pregunto 
LaHudra. 

“Claro que sf \ respondio Goniff. “Un par de platos aqui, otros alia, pronto las perdidas 
seran considerables. Pero hay algo de los meseros que me esta molestando mas.” 

“i,Y que es?”, pregunto Nar. 

“Los reportes indican que se estan enfermando demasiado. Es bueno eso de que tenga- 
mos toda esta tecnologia en los restaurantes. Nos ayuda cuando tenemos que trabajar con 
limitaciones en el personal: por lo general los meseros pueden hacerse cargo de mayores 
secciones de lo que podrian normalmente.” 

“Veamos que ocurre”, dijo LaHudra. 

La madre de la invention 

Los tres socios entrevistaron a varios de los meseros que se habian enfermado con fre- 
cuencia en los dos ultimos meses, e hicieron un asombroso descubrimiento: los platos 
rotos y los dfas de enfermedad estaban relacionados. Los meseros habian estado mane- 
jando y empunando sus palmtops tanto que sus munecas habian comenzado a debilitarse. 
Tal como una saliente puede hundir embarcaciones, una muneca debil puede dejar caer 
los platos. Lo que es mas, habian tenido tanto dolor en sus munecas que no podian ir a 
trabajar. 

“i,No podnamos ayudar a estas personas de alguna forma?”, pregunto desconsolado Nar. 

“^Y en el proceso ayudamos a nosotros mismos?”, contra argumento el oportunista 
Goniff. 

“Tal vez haya alguna forma de que les ayudemos a mejorar sus fuerzas y sus munecas”, 
dijo LaHudra. 

“Bien, ^,que haremos?”, pregunto Goniff, “^comprar a cada uno un ejercitador de munecas?” 

“Podna ser peor”, dijo LaHudra, “pues no se que tan efectivos sean tales ejercitadores. 
Podrfa ser eterno el proceso de curacion de nuestro personal”. 




“Con todo, la idea es buena”, dijo Nar, “tal vez solo necesitemos un ejercitador de mune- 
cas mejor que el que se pudiera adquirir en algun establecimiento”. 

“^,En verdad? ^Como podrfamos hacer un mejor ejercitador de munecas?”, pregunto 
LaHudra. 

No tuvo que esperar mucho la respuesta. Nar estaba en uno de sus papeles de querer 
patentar. 

“Recuerdo que mucha gente cree que la mejor y mas eficiente forma de ejercitarse es 
aquella que genera el mayor reto, cuando sus musculos estan trabajando a su maxima 
potencia. Si podemos crear un ejercitador de munecas que aumente su resistencia con- 
forme los musculos del antebrazo trabajen mas, apuesto que mejoraremos la fuerza de 
las munecas de nuestros meseros en la mitad del tiempo que ocuparfan con un ejercitador 
de munecas comun ” 

“Y, ^como harfamos eso?” se preguntaba el siempre pragmatico LaHudra. 

“Tal como revolucionamos al negocio de los restaurantes”, dijo Nar, “con tecnologia”. 

“A ver, esperame”, dijo LaHudra, “lo que hicimos en los restaurantes requirio el uso de 
computadoras. ^Realmente quieres decirme que agregaremos una computadora a un 
ejercitador de munecas?” 

“^Y por que no?” dijo Nar. 

“jCierto! ^Por que no?”, replied Goniff. “Ya te entendf, Nar. Y cuando terminemos de 
generar este aparato, podriamos comercializarlo. Y ya tengo el nombre perfecto: ^Que tel 
‘LNG TecnoApreton’?” 

“Creo que me esta gustando”, dijo, con cautela, LaHudra. 

“Ya me gusta”, indico Nar, con entusiasmo. “^Donde esta ese equipo de desarrollo?” 

Creadon de TecnoApreton 

El equipo de desarrollo de RICO se ha vuelto a reunir. Su nueva mision sera la de generar 
TecnoApreton, una pulsera “inteligente” para la muneca y el antebrazo que de una 
resistencia variable durante los movimientos repetitivos de un ejercicio: cuanto mas tra- 
bajen los musculos, mayor sera la presion de TecnoApreton. 

Durante la realizacion de la idea, el equipo hizo algunas investigaciones para ver como 
medir que tanto trabaja un musculo. Aprendieron lo referente a senales electricas de las 
fibras activas de los musculos. Tales senales, llamadas EMG (siglas de senales Electro- 
miograficas), son el fundamento de fascinantes dispositivos que permiten a los discapaci- 
tados manejar equipo electronico. 




Esto no sera un tratado de ciencia-ficcion. En los primeros anos de la decada 
de los noventa, el neurocientffico David Warner del Centro Medico de la 
Universidad Loma Linda coloco electrodos en el rostro de un muchacho y lo 
conecto a una computadora. El muchacho, completamente paralizado del 
cuello para abajo en un accidente automovilistico, pudo mover objetos en la 
pantalla de la computadora al tensar algunos de sus musculos faciales. 

Para aprender mas respecto a esta emocionante area, lea el articulo de 
Hugh S. Lusted y Benjamin Knapp, "Controlling Computers with Neural 
Signals", en la revista de octubre de 1996 de Scientific American. 



El equipo concluyo que podrfan capturar estos EMGs mediante pequenos y economicos 
“electrodos de superficie” colocados en el antebrazo, pasar los EMGs capturados por 
una computadora y, luego, utilizarlos como base para que la computadora ajuste la 
resistencia en el ejercitador de munecas. Esto trae consigo la captura y analisis de datos 
en tiempo real, dado que los ajustes tienen que hacerse tan pronto como el musculo se 
contrae. 

Una posibilidad del diseno serfa colocar el electrodo de superficie en el antebrazo, 
conectarlo a una computadora de escritorio para que analice los EMGs y haga los ajustes 
necesarios al ejercitador de munecas. La ventaja serfa que posibilitarfa la presentation de 
diversos datos en la pantalla, imprimir informes del progreso, y analizar las tendencias. 
No obstante, la des ventaja serfa que la persona quedarfa atada a la computadora. 

Otra posibilidad es la de incrustar un chip de computadora directamente en el ejercitador 
de munecas para que la persona pueda moverse a donde desee mientras utilice 
TecnoApreton. La figura 23.1 muestra como lucirfa este diseno. En cada repetition del 
ejercicio, la persona aprieta la barra de constriction y la mueve hacia la barra base. 

La ventaja del diseno incrustado serfa que el usuario podrfa utilizar un dispositivo como 
este en casi cualquier lugar (si la computadora tiene suficiente energfa en las baterfas). 

La desventaja, claro, es la perdida de la information potencial que pudiera almacenar y 
mostrar una computadora de escritorio. 

Las sesiones JAD dejaron entrever que todos serfan mas felices con el segundo diseno, y 
ello nos ileva hacia el mundo maravilloso de los sistemas incrustados. 
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tQue es un sistema incrustado? 

A estas alturas, ya sabe que las computadoras estan por doquier. Lo que tal vez no sepa 
es que tanto territorio abarca ese “doquier”. Las computadoras que ve a su alrededor son 
solo la punta del tempano. Muchas de ellas se encuentran ocultas en lugares de dificil 
acceso: dentro de los electrodomesticos, automoviles, aeroplanos, maquinaria de fabrica, 
dispositivos biomedicos y otros. Hay procesadores medianamente poderosos dentro de 
las impresoras. 

Todas esas computadoras que no se ven a simple vista son ejemplos de sistemas incrusta- 
dos. Siempre que tenga un dispositivo “inteligente”, tendra un sistema incrustado. 

Los sistemas incrustados no tienen teclados y monitores que interaccionen con nosotros, 
en vez de ello, cada uno es un chip que se encuentra dentro de un dispositivo (como un 
aparato electrodomestico), y ese dispositivo no se parece para nada a una computadora. 

El sistema incrustado decidira que debe hacer el dispositivo. 

Si utiliza un sistema de este tipo, no tendra la sensation de trabajar con una computado- 
ra. En vez de ello, estara interactuando con un dispositivo. Le apuesto que nunca sabra 
que hay un chip de computadora dentro. Cuando tuesta una rebanada de pan, no le preo- 
cupa que un chip de computadora este distribuyendo el calor — solo quiere su pan 
tostado. 




Cuando termina de trabajar con su computadora, la apaga. Un sistema incrustado por lo 
general no se puede dar esos lujos. Una vez que se le coloca, un sistema tiene que traba- 
jar por dfas o anos (como en un marcapasos). 

Si un procesador de textos o una hoja de calculo tienen un error y su sistema se colapsa, 
simplemente vuelve a arrancarlo. Si el software en un sistema incrustado falla, los resul- 
tados pueden ser desastrosos. 

Por lo tanto, un sistema incrustado no realiza el computo de la forma habitual. Se le 
coloca para ayudar a otro tipo de dispositivo a hacer su trabajo. El otro dispositivo es el 
que es manejado por el usuario y se integra al entomo. 

Como podra imaginar, programar un sistema incrustado no es para novatos. Requiere 
mucho conocimiento del dispositivo donde se encontrara el sistema: que tipo de senales 
enviara, que tipo de parametros de cronometraje tendra y otras cosas. 

Conceptos de los sistemas incrustados 

Veamos de cerca los sistemas incrustados y lo que comunmente tienen que hacer. En las 
siguientes subsecciones examinaremos algunos de los conceptos mas importantes de un 
sistema incrustado. 

Tiempo 

Si revisa el tema hasta donde vamos, vera que el tiempo se destaca en el mundo de los 
sistemas incrustados. De hecho, el tiempo es la base para clasificar a los sistemas incrus- 
tados como tolercintes o estrictos. 

Un sistema tolerante hace su trabajo tan pronto como sea posible sin tener que cumplir 
con plazos especificos. Un sistema estricto tambien tiene que hacer su trabajo tan pronto 
como sea posible, pero debera finalizar sus tareas de acuerdo con plazos rigurosos. 

Subprocesos 

En el mundo de los sistemas incrustados, un subproceso (que tambien se conoce como 
tarea) es un simple programa. Es una section de una aplicacion, y realiza cierto trabajo 
significativo dentro de ella. Intenta obtener toda la atencion de la CPU. La multitarea es 
el proceso de programar el tiempo de la CPU para que trabaje con varios subprocesos y 
atienda a uno y otro. 

Cada subproceso cuenta con un numero que establece su prioridad dentro del programa 
de aplicacion, y que se relaciona — por lo general — con uno de seis estados: 

• inactivo: esta en la memoria y no se ha hecho disponible al sistema operativo 

• listo: puede ejecutarse, pero el subproceso que esta en ejecucion tiene una priori- 
dad mayor 




• suspendido : se ha interrumpido a si mismo por cierto tiempo 

• a la espera de un evento : algo debe ocurrir para que se ejecute 

• ejecucion: cuando esta siendo atendido por la CPU 

• interrumpido : poque la CPU se esta ocupando de una interrupcion 

La figura 23.2 le muestra un diagrama de estados que representa a estos estados y las 
transiciones entre ellos. Observe la ausencia de un simbolo de inicio y otro de fin. Esto le 
indica que el subproceso fluye de un estado a otro en un ciclo infinito. 



Figura 23.2 
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Por cierto, ^que es una “interrupcion”? Continue leyendo. 

Interrupciones 

Una interrupcion es un elemento pequeno de mucha importancia en un sistema incrus- 
tado. Es un mecanismo basado en hardware que le indica a la CPU que ha acontecido un 
evento asincronico. Un evento es asincronico si sucede de forma impredecible (esto es, 
fuera de sincroma). Por ejemplo: en el TecnoApreton, las senales EMG llegan de forma 
asincronica. 

Cuando la CPU reconoce una interrupcion, guarda lo que estaba haciendo e invoca a un 
ISR (Rutina para el servicio de interrupciones) que procesa al evento. Cuando el ISR 
finaliza su trabajo, la CPU continua con lo que hacia cuando sucedio la interrupcion. 









Despues de procesar una interrupcion, el lugar a donde regresara la CPU 
se determina por el tlpo de sistema operative* que en ella se ejecuta, como 
lo vera posteriormente. 



Las interrupciones son importantes dado que permiten que una CPU se libere de lo que 
esta haciendo y procese los eventos conforme suceden. Esto es tremendamente significa- 
tive para un sistema en tiempo real que tenga que responder a eventos del entomo de 
manera oportuna. 

Ya que la puntualidad es tan importante, los sistemas incrustados tienen que ocuparse del 
curso del tiempo en una interrupcion y su procesamiento, aunque tal lapso pudiera pare- 
cer infinitesimal. La CPU tiene que tomar algo de tiempo desde que se le notifica de la 
interrupcion hasta que guarda lo que estaba haciendo (esto es, su contexto). A ello se le 
conoce como latencia de la interrupcion. La respuesta de la interrupcion es el tiempo 
entre la llegada de la peticion de interrupcion y cuando la CPU inicia el ISR. A1 fmalizar 
el ISR, la recuperacion de la interrupcion es el tiempo que le lleva a la CPU regresar a 
donde estaba — a su contexto — cuando ocurrio la interrupcion. 

Hay un tipo de interrupcion especial: los ciclos del reloj. Como un “latido de corazon” 
del sistema, el ciclo del reloj sucede en intervalos regulares especificos de una aplicacion 
(por lo general entre 10 y 200 microsegundos). Los ciclos del reloj determinan las 
restricciones de tiempo de un sistema incrustado. Por ejemplo: un subproceso en estado 
suspendido permanecera asf durante una cantidad especffica de ciclos. 

Sistema operativo 

Un sistema operativo en tiempo real (RTOS) funciona como un policia de transito entre 
los subprocesos y las interrupciones; media la comunicacion entre subprocesos y entre una 
interrupcion y un subproceso. El nucleo o kernel es la parte del RTOS que administra el 
tiempo que utiliza la CPU en subprocesos individuales. El programador del nucleo deter- 
mina cual subproceso se ejecuta despues. Como lo mencione, cada subproceso tiene una 
prioridad asignada. 

Los nucleos pueden ser preferenciales o cooperativos (no preferenciales), de acuerdo 
con la forma en que se encarguen de las interrupciones. En un nucleo cooperative 
cuando se termina la ejecucion de un ISR, la CPU regresa al subproceso en que se 
encontraba cuando llego la peticion de interrupcion. Un nucleo cooperativo se dice que 
se involucra en la multitarea cooperativa. La figura 23.2 se aplica al nucleo cooperativo. 

Por otro lado, en un nucleo preferencial, cuando finaliza un ISR, la CPU verifica la prio- 
ridad de los subprocesos que se encuentren en el estado de Listo. Si uno de los subproce- 
sos tiene una mayor prioridad que la tarea interrumpida, la CPU ejecutara dicho 
subproceso en lugar de aquel en el que se encontraba cuando se recibio la peticion de 
interrupcion. Por ello, la tarea de mayor prioridad tiene preferencia sobre la tarea inte- 
rrumpida. La figura 23.3 muestra la modificacion a dos de los estados en la figura 23.2, 
para modelar al nucleo preferencial. 




Figura 23.3 






Modification de tran- 
sitions entre dos 
estados en la figura 
23.2 para reflejar lo 
que ocurre en un 
nucleo preferential. 




Listo 



) 



La Figura 23.4 modela el nucleo cooperative como un diagrama de secuencias, y la 
figura 23.5 hace lo propio para el nucleo preferencial. 



Figura 23.4 

Diagrama de secuen- 
cias para el nucleo 
cooperativo. 
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Microsoft empezo a reducir la brecha hacia el dominio de los sistemas in- 
crustados. Esta comercializando, de Windows CE, el sistema operativo para 
dispositivos de mano, al igual que para sistemas incrustados. Windows CE 
esta generado de forma modular. Para ajustarse a una CPU en particular y a 
una aplicacion incrustada, solo requiere utilizar los modulos que necesite 
para que funcione. 

La ventaja de utilizar Windows CE es que podra utilizar el popular conjunto 
de herramientas de Microsoft junto con Visual C++ para generar un sistema 
incrustado. 









Figura 23.5 



Diagrama de secuen- 
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preferencial 




Aunque hemos visto bastantes fundamentos, tenga en cuenta que solo hemos visto cues- 
tiones superficiales de los sistemas incrustados. 

Modelado de TecnoApreton 

De regreso a la tarea (^subproceso?) que dejamos suspendido, empezaremos a crear un 
modelo para TecnoApreton. Aunque no es el caso de que todos los sistemas incrustados 
esten orientados a objetos, aun podemos utilizar tal orientacion para modelar al sistema y 
su comunicacidn con el mundo exterior. 

A partir de nuestro tema de los sistemas incrustados, es claro que tenemos que tomar en 
cuenta el cronometraje, los eventos, los cambios de estado y las secuencias. 

Clases 

Como en el caso de cualquier otro tipo de sistema, empezaremos con las clases. Para 
comprender la estructura de clases, empezaremos con una descripcion resumida de 
TecnoApreton y la forma en que funciona. Este resumen pudo haber sido el resultado de 
un analisis del dominio. 

He aqui la descripcion. TecnoApreton consta de un electrodo de superficie, una CPU, un 
accionador (para realizar los comandos de ajuste provenientes de la CPU), y un conjunto 
de cinco resortes. El accionador se conecta a los resortes mediante una interfaz mecanica. 
TecnoApreton recibe senales EMG asincronicas de un electrodo de superficie y las pasa 
a la CPU. Cada EMG provoca una petition de interruption, misma que la CPU tratara 









con un ISR. El software en la CPU analiza las senates. Cuando el analisis esta complete, 
la CPU envia una serial a un accionador para ajustar la tension en los resortes. El actua- 
dor hace el ajuste mediante el manejo de la interfaz mecanica con los resortes. 

La figura 23.6 muestra una estructura de clases que resume al parrafo anterior. Observe 
que el borde de la CPU esta en negritas, lo que indica que es una clase activa. La idea 
es que la CPU siempre tendra el control (en la recepcion, analisis de senales y la admi- 
nistration de los ajustes). Tambien realiza algunas tareas internas del sistema. Observe, 
a su vez, el uso de una clase de asociacion para MensajeDe Ajuste, que nos permite 
establecer parametros al mensaje. 



Figura 23.6 

Estructura de clases 
de TecnoApreton. 




SenialEMG y MensajeDeAjuste son importantes, asi que nos enfocaremos en ellos. El 
sistema estara interesado en el momento en que llegue una serial y su potencia, por lo 
que horaDeLlegada y amplitud parecen ser atributos razonables para SenialEMG. A su 
vez, la SenialEMG tendra indudablemente caracterfsticas complejas que estan fuera del 
ambito de este tema. 

Para MensajeDeAjuste, tanto horaDeGeneracion y cantidad Ajuste parecen ser atributos 
razonables. 

La figura 23.7 muestra los atributos de estas clases. 










Figura 23.7 

Una mirada mas 
cercana a SenialEMG 
y MensajeDeAjuste. 
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Casos de uso 

La sesion JAD que mencione anteriormente (que dio por resultado la decision de disenar 
un sistema incrustado en lugar de una computadora de escritorio), tambien dio por resul- 
tado varios casos de uso, como se aprecia en la figura 23.8. 



Figura 23.8 

Los casos de uso de 
TecnoApreton . 




Estos casos de uso determinan las facultades por generar en el sistema. “Encender” 
incluye a “Realizar una auto-prueba” la cual, a su vez, incluye “Verificar el electrodo” y 
“Verificar la CPU”. 

“Seleccionar uso” se refiere a diversas formas de ajustar el TecnoApreton, muchas de las 
cuales no se le ocurrieron al Sr. Nar cuando penso en este dispositivo. Por ejemplo: los 
participantes de la JAD dijeron que les gustarfa establecer repeticiones “negativas”: una 
resistencia limitada cuando aprieten las barras, y una maxima cuando dejen de apretar. 

Esto significa que debemos agregar un atributo a MensajeDeAjuste para reflejar el 
uso del sistema. Podrfamos llamarlo algoritmoDeUso y darle los valores posibles de 
aumentarTension y repNegativa. La figura 23.9 muestra la clase MensajeDeAjuste mo- 
dificada. 






Figura 23.9 
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Interacciones 

Ahora prestemos atencion a “Apretar la barra”, y asumamos que la persona ha selec- 
cionado el modo originalmente concebido: incrementar la resistencia al incrementarse la 
actividad muscular. En esta parte del modelo, tenemos que aseguramos de considerar 
restricciones de tiempo y cambios de estado. Asumamos que un intervalo de ciclos del 
reloj es de 20 microsegundos, y que el lapso desde que se recibe una senal hasta enviar 
un mensaje de ajuste no debera ser mayor de 10 ciclos del reloj. 

Una conjetura mas: supongamos que el nucleo RTOS funciona de forma preferencial. 

Elio requiere de algunas pequenas decisiones de modelado. Para empezar, y para reflejar 
la operation del nucleo, vamos a tratar las operaciones de analizar(), ajustar() y 
tareasIntemasO de la CPU como subprocesos, y les asignaremos prioridades. 

Para mostrarlas en nuestro modelo, tenemos que tratarlas como clases (algo que no sole- 
mos hacer con las operaciones). Este es un ejemplo de UML avanzado llamado concre- 
tion : tratar algo como si fuera una clase (u objeto) que no se suele tratar asf. Cuando lo 
haga, enriquecera a su modelo porque sus clases concretadas tendran relaciones con otras 
clases, tendran sus propios atributos y se convertiran en estructuras que podra manipular 
y almacenar. En este caso, la concretion nos permite mostrar las prioridades de los sub- 
procesos como atributos y utilizar los subprocesos en nuestros diagramas de interaccidn. 

La figura 23. 10 muestra la estructura de clases de los subprocesos de TecnoApreton. 



Figura 23.10 

Estructura de clases 
para los subprocesos 
de TecnoApreton. 






^Como podnamos dar prioridades a nuestros subprocesos? Cuando llegue una petition 
de interruption, la CPU tendrd que detener lo que hacia, guardar su contexto y atender 
la interruption con un ISR. Nuestra operation procesarISR() toma la amplitud de 
SenialEMS y las otras caracterfsticas de senal compleja y las inserta en la memoria para 
analizar() para trabajar en las mismas. Entonces la operation analizar() debe tener la 
maxima prioridad. Seguira la operation ajustar(). La operation tareaslntemas() debe 
tener la menor prioridad. 

He aqui un ejemplo de como todo esto funcionarfa en conjunto de una manera preferen- 
tial. Si la CPU esta a la mitad de la ejecucion de algunas operaciones intemas y llega 
una senal, interrumpira lo que este haciendo. La CPU ejecutara procesarISR() y obtendra 
los valores adecuados de la senal. ^Que ocurre despues? Regresar a las tareas intemas no 
serfa productivo. En vez de ello, la CPU ejecutara la operation de mayor prioridad, 
analizarQ, seguida por ajustar(). 

La figura 23. 1 1 le muestra el diagrama de secuencias para “Apretar la barra”. La figura 
23.12 le muestra un diagrama de colaboraciones para este caso de uso. En ambos diagramas 
utilizamos Haves para indicar restricciones de tiempo (medidas por ciclos del reloj). 



Figura 23.11 

Diagrama de secuen- 
cias para “Apretar la 
barra 



















Figura 23.12 

Diagrama de colabo- 
raciones para 
“Apretar la barra 




Cambios de estado generales 

Ademas de los cambios de estado dentro de una interaction, podemos examinar los cam- 
bios de estado en todo el sistema. Por lo general, esperamos que TecnoApreton este en 
modo de Trabajo o en modo de Reposo (por ejemplo, entre lapsos de un ejercicio). 
Tambien podrfa estai en el estado de Apagado. Como podrfa imaginar, el estado Trabajo 
es un objeto compuesto. La figura 23.13 muestra los detalles. 



Figura 23.13 

Cambios de estado de 
TecnoApreton . 











Distribution 

iQue tal lucirfa TecnoApreton una vez que se lleve a cabo? La figura 23.14 es un diagra- 
ma de distribucion que muestra las partes del sistema, junto con una bateria que suminis- 
tra la energfa. 



Figura 23.14 

Un diagrama de 
distribucion para 
TecnoApreton. 



«Dispositivo» 
Electrodo superficial 



/ 


7 


«Dispositivo» 




Bateria 


/ 






A , 


71 



CPU 
preferencial 



/ 


7 


«Dispositivo» 




Actuador 


7 



«Dispositivo» 
Interfaz con 
los resortes 


) 








z 




7 


«Dispositivo» 

Resortes 


/ 



Flexiones en sus musculos 

Cuando los socios recibieron los diagramas UML de TecnoApreton, empezaron las 
maquinaciones. 

“Este es un concepto que podrfamos expandir”, dijo Goniff. 

“^Como?”, pregunto Nar. 

“Piensenlo. ^Cuantos musculos hay en el cuerpo humano? Podriamos crear un disposi- 
tivo ejercitador inteligente que se centre en varios de ellos.” 

“Ah, isiT pregunto nuevamente Nar, cautivado. 

“jClaro!”, dijo Goniff. “Si llevamos el concepto de resortes, electrodos y CPU un poco 
mas alia, podrfamos desarrollar una barra con pesas portatil e inteligente que la gente 
podrfa llevar consigo cuando viajara. No pesarfa mucho, dada la liviandad de los resortes 
que darfan la resistencia y la CPU que darfa la inteligencia. Podriamos llamarlo: 
‘TecnoPesas’ ” 

“Sf dijo Nar, “o podriamos seguir otro derrotero y hacer maquinas por separado para 
cada parte del cuerpo”. 

“jAsf es! Algo asf como TecnoPecho’.” 

“O ‘TecnoBrazo’”. 

“O TecnoPiema’.” 







“^Que tal ‘TecnoAsentadera’?” 

En este momenta, LaHudra ya no podfa soportar mas. 
“Tengo uno para ustedes dos”, les dijo a sus socios. 
“^Cudl ?” preguntaron al unfsono. 

“TecNoSePasen .” 



Resumen 

Un sistema incrustado es una computadora que se encuentra dentro de algun otro dispo- 
sitivo, como un electrodomestico. La programacion de un sistema incrustado requiere 
mucho conocimiento del dispositivo donde se encontrara el sistema. Un sistema incrus- 
tado podrfa ser tolerante, significa que no tiene que cumplir con plazos rigurosos, o 
estricto , que si tiene que cumplir con ellos. 

El tiempo, los subprocesos (programas sencillos que son partes de una aplicacion) y las 
interrupciones (dispositivos de hardware que dejan saber a la CPU que ha ocurrido algo) 
son conceptos importantes en los sistemas incrustados. Un interruptor en particular, el 
ciclo del reloj, sucede a intervalos regulares y funciona como un latido del corazon del 
sistema. 

Un sistema operativo en tiempo real (RTOS) dirige el trafico entre subprocesos e 
interrupciones. El nucleo es la parte del RTOS que administra el tiempo que ocupa la 
CPU en subprocesos individuates. El programador de tiempo del nucleo determina cual 
tarea se ejecutara a continuation. Un nucleo puede ser preferencial (en el que un sub- 
proceso de mayor prioridad tiene preferencia sobre uno de baja prioridad cuando finaliza 
una rutina para el servicio de interrupciones) o cooperativo (en el que la tarea interrum- 
pida continua despues que la rutina para el servicio de interrupciones finaliza). 

Estos conceptos los aplicamos mediante el modelado de un inteligente dispositivo ejerci- 
tador que varfa su resistencia en funcion de la fuerza con que trabaje un musculo. 

Preguntas y respuestas 

P Usted hablo de sistemas 44 inteligentes’\ ^Tales sistemas incrustados incluyen 
algo como la Inteligencia Artificial? 

R Asi es. Una variedad de la IA, llamada “logica vagamente definida” o “fuzzy 
logic”, se encuentra en el corazon de diversos tipos de sistemas incrustados. 

P £Un tipo de RTOS es mas adecuado que otro para cierto tipo de aplicaciones 
de sistemas incrustados? 

R Si. Un tipo del cual no di mayores explicaciones, el superciclo, es el RTOS mas 
sencillo. Con frecuencia esta incrustado en aplicaciones de alto volumen como los 
juguetes. El nucleo preferencial es el RTOS elegido para sistemas complejos. 




Taller 

He incrustado algunas preguntas para verificar su nuevo conocimiento, y las respuestas 

estan incrustadas en el Apendice A, “Respuestas a los cuestionarios”. 

Cuestionario 

1. ^Que es un sistema incrustado? 

2. ^Que es un evento asincronico? 

3. En terminos de sistemas incrustados, ^que es un sistema “estricto” y que un sistema 
“tolerante”? 

4. iQue sucede en un “nucleo preferential”? 

Ejercicios 

1 . Imaginese un sistema incrustado para un tostador. Asuma que el tostador cuenta 
con un sensor que analiza una rebanada de pan y su nivel de tueste. Asuma, a su 
vez, que puede establecer que tan tostado desea su pan. Dibuje un diagrama de 
clases para este sistema. Incluya al sensor, la CPU y el elemento calentador (;y la 
rebanada de pan!). 

2. Dibuje un diagrama de secuencias para el sistema incrustado del tostador. Justifique 
su eleccidn de un nucleo preferencial o uno cooperativo. Y, aprovechando el viaje, 
dibuje tambien un diagrama de distribucion. 
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El futuro del UML 

Por ultimo, analizaremos algunas extensiones actuales del UML y algunas 
extensiones potenciales. 

En esta hora se trataran los siguientes temas: 

• Extensiones para los negocios 

• Lecciones de las extensiones de negocios 

• Interfaces graficas de usuario 

• Sistemas expertos 

Hemos llegado a la ultima hora. Ha sido un largo trecho, pero en el proceso 
hemos visto mucho del UML. En las ultimas dos horas ha visto aplicaciones 
en areas innovadoras. En esta hora, veremos un panorama de todo con una 
extension actual UML y una mirada a otras areas de aplicacion del UML. 

Hemos tratado las extensiones del UML en la hora 14, “Nociones de los 
fundamentos del UML”. Como lo indicamos entonces, puede extender el 
UML mediante la adicion de estereotipos que le permitan hacer su propio 



modelo de su dominio. Tambien podra agregar estereotipos graficos que aclaren la infor- 
mation trasladada a su modelo. Los diagramas de distribution son buenos ejemplos de 
ello porque las figuras con frecuencia sustituyen a los iconos cubicos del UML. 

La meta de esta hora es que empiece a pensar en como podrfa aplicar el UML en su 
dominio. Como cualquier lenguaje, el UML se encuentra en proceso de evolution. 

Su futuro depende de como lo utilicen y lo extiendan los modeladores. 

Extensiones para los negocios 

Una extension popular es un conjunto de estereotipos disenados para modelar un nego- 
cio. Los estereotipos abstraen ciertas ideas primordiales de las que se conforma un 
negocio. Podra visualizarlas en terminos de sfmbolos UML que ya conoce o como 
iconos especializados (creados por el Amigo del UML Ivar Jacobson). La intention es la 
de modelar situaciones del mundo de los negocios, en lugar de que funcionen como los 
fundamentos para la construction del software. 

Dentro de un negocio, la clase obvia es trabajador. En el contexto de esta extension 

UML, un trabajador actua dentro de los negocios, interactua con otros traba- 
jadores y participa en los casos de uso. Un trabajador puede ser un trabajador 
interno o un trabajador eventual. Un trabajador intemo interactua con otros trabajadores 
dentro de los negocios, y un eventual lo hace con los actores fuera de los negocios. Una 
entidad no inicia ninguna interaction, pero participa en los casos de uso. Los traba- 
jadores interactuan con las entidades. 

La figura 24.1 le muestra la acostumbrada notation UML para estos estereotipos, junto 
con los iconos especializados. Para cada uno, he incluido un ejemplo del dominio res- 
taurante. 

Las extensiones de negocios incluyen a dos estereotipos de asociacion: «comunica» y 
«suscribe». El primero es para las interacciones entre objetos. El segundo 
describe una asociacion entre un origen (llamado suscriptor ) y un destinatario 
(llamado publicador). El origen establece un conjunto de eventos. Cuando uno de esos 
eventos sucede en el destinatario, el origen recibe una notification. 

Las entidades se combinan para conformar unidades de trabajo , que son conjuntos de 
objetos orientados a tareas. Las unidades de trabajo, las clases y las asocia- 
ciones se combinan para conformar unidades organizativas. Una unidad orga- 
nizativa (que puede incluir a otras unidades organizativas) corresponde a una unidad 
organizativa del negocio. 
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Figura 24.1 



Estereotipos para el 

modelado de negocios . «Trabajador» 

Gerente 



Gerente 



«Trabajador interno» 

Chef 




Chef 



«Trabajador eventual» 

Capitan de meseros 




Capitan de meseros 



«Entidad» 

Orden 




Lecciones de las extensiones de negocios 

Las extensiones de negocios nos ensenan algunas lecciones importantes. Para empezar, 
es evidente que con algo de imagination es posible utilizar iconos sencillos y representa- 
ciones que capturen aspectos fundamentales del dominio. El mundo operativo es “sen- 
cillo”. En segundo termino, las representaciones nos ayudan a pensar respecto a, 
y a crear soluciones en, un dominio. 

Tomaremos en cuenta tales lecciones conforme exploremos y llevemos al UML a dos 
importantes proyectos de modelado: las interfaces graficas de usuario y los sistemas 
expertos. 

Interfaces graficas de usuario 

Un sello de los paquetes contemporaneos de software, la GUI (interfaz grafica de usuario) 
ha liegado para quedarse. GRAPPLE y otros procesos y metodologfas de desarrollo se 
aplican a una sesion JAD para la creation de la GUI de una aplicacion. 






En un documento de diseno, por lo general, incluira capturas de pantalla para mostrar a 
sus clientes y desarrolladores como lucira la GUI a los usuarios. Por varias razones, aun 
podna necesitar un diagrama especializado para modelar una GUI. 

Conexiones a casos de uso 

La razon primordial tiene que ver con los casos de uso. Como la mayor parte de un 
proyecto de desarrollo, el desarrollo de la GUI esta conducido por casos de uso. De 
hecho, la GUI se conecta directamente con los casos de uso porque es la ventana por la 
cual el usuario final iniciara y completara los casos de uso. Podna ser diftcil utilizar cap- 
turas de pantalla para establecer la relation entre las pantallas y los casos de uso. 

Otra ra/on es que probablemente necesitemos capturar la evolution en el proceso de 
razonamiento conforme la GUI tome forma. En GRAPPLE, el desarrollo de la GUI ini- 
cia cuando los usuarios finales que participen en la sesion JAD maniobren las notas 
autoadheribles (que representan controles en la pantalla) en grandes hojas de papel (que 
representan pantallas). Podna ser util contar con un tipo de diagrama que capture los 
resultados de tales maniobras de manera directa (uno que un modelador pueda modificar 
con facilidad, cuando los participantes de la sesion JAD modifiquen el diseno). 

Un diagrama que muestre las conexiones de las pantallas con los casos de uso ayudarfa a 
los que participan en la sesion JAD a recordar lo que se supone que hara cada pantalla 
cuando coloquen los componentes de la misma. Mostrar las conexiones con los casos de 
uso tambien ayudara a asegurar que todos los casos de uso sean instaurados en el diseno 
final. 

Modelado de la GUI 

Un modelo tfpico en UML podna representar a una ventana de una aplicacidn particular 
como un objeto compuesto de varios controles, como se ve en la figura 24.2. 



Figura 24.2 

Un modelo UML 
de una ventana. 




Podrfamos utilizar atributos para agregar una ubicacion en el espacio de cada componente: 
una ubicacion horizontal y una vertical medida en pfxeles. Otro par de atributos podna re- 
presentar al tamano del componente (alto y ancho). No obstante, es mas facil abarcar 
ambos componentes si los visualizamos. Podnamos especificar que un paquete represen- 





tara a una ventana, y que la ubicacion y tamano de los objetos dentro del paquete refleje su 
ubicacion y tamano en la ventana. La figura 24.3 hace lo que indique. 



Figura 24.3 

Modelo de una 
ventana que muestra 
la ubicacion de los 
componentes . 




La figura 24.4 es el diagrama hibrido que agrega el toque final al mostrar las conexiones 
con los casos de uso. 



Figura 24.4 

Modelado de una ven- 
tana que muestra la 
forma en que los com- 
ponentes de la pan- 
talla se conectan a los 
casos de uso. 






Este tipo de modelado no evita que se muestren las capturas de pantalla. En lugar de ello, 
podrfa ser una adicion util: un diagrama esquematico que se centre en el panorama gen- 
eral. 

Sistemas expertos 

Los sistemas expertos surgieron a la popularidad en la decada de los anos ochenta. 
Cuando aparecieron no fueron mas que una curiosidad, pero hoy son parte de la 
corriente principal del computo. 

Un sistema experto esta disenado para capturar el conocimiento y experiencia de una 
persona versada en un dominio especifico. Almacena esa experiencia en un programa de 
computo. La intencion es utilizar al sistema experto para responder a preguntas repeti- 
tivas para que la persona experta no tenga que hacerlo, o almacenar la experiencia para 
que este disponible cuando la persona no lo este. 

Componentes de un sistema experto 

La experiencia se encuentra en la base de conocimientos del sistema experto, 
como un conjunto de reglas condicionales if-then (si-entonces). La parte if de 
la condition describe ciertas situaciones reales en el dominio del experto. La parte then 
establece las acciones por realizar en tal situation. ^De que manera se registra la expe- 
riencia en la base de conocimientos? Un ingeniero de conocimiento realiza extensas 
entrevistas con un experto, graba los resultados y los presenta en software. Es similar a la 
entrevista que se realiza en un analisis de dominio, aunque las sesiones para la ingenierfa 
del conocimiento son, por lo general, mas extensas. 

La base de conocimientos no es el unico componente en un sistema experto. Si lo fuera, 
un sistema experto podria ser tan solo una lista de reglas condicionales if-then. Lo que 
se necesita es un mecanismo para operar a lo largo de la base de conocimientos para 
resolver un problema. A tal mecanismo se le conoce como motor de deducciones. Otra 
pieza necesaria del rompecabezas es un area de trabajo que contenga las condiciones de 
un problema que el sistema tenga que resolver. Claro esta que otro componente mas es la 
interfaz del usuario para indicar las condiciones del problema. La captura de condiciones 
podria realizarse mediante una lista de verification, preguntas y respuestas de option 
multiple o un sistema extremadamente sofisticado sentado en el idioma natural. La figura 
24.5 le muestra un diagrama de clases UML de un sistema experto. 

Para interactuar con un sistema experto, el usuario captura las condiciones de un pro- 
blema en la interfaz del usuario, misma que las almacena en el area de trabajo. El motor 
de deducciones se vale de tales condiciones para buscar una solution en la base de 
conocimientos. La figura 24.6 presenta un diagrama de secuencias para este proceso. 
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Figura 24.5 

Diagrama de closes de 
un sistema experto. 



Figura 24.6 

Interaccion con un 
sistema experto. 







El area de trabajo podrfa equipararse a la memoria temporal (datos en cache), en tanto 
que la base de conocimientos serfa la memoria permanente (datos en disco) y el motor de 
deducciones serfa el proceso para resolver el problema. 

Un ejemplo 

Un motor de deducciones por lo general analiza su base de conocimientos en una de dos 
formas, y la mejor manera de explicarlo es mediante un ejemplo. Suponga que tenemos 
un sistema experto que captura la experiencia de un fontanero. Si uno de sus grifos 
gotea, utilizarfa al sistema experto y le explicarfa el problema. El motor de deducciones 
harfa el resto. 

Dos de las reglas en su base de conocimientos podrfan lucir asi: 

Regia 1: 

SI tiene un grifo que gotea 

Y el grifo es de compuerta 

Y la gotera esta en la manija 
ENTONCES ajuste el empaque 
Regia 2: 

SI el empaque estd ajustado 

Y la gotera persiste 
ENTONCES reemplace el empaque 

Sin profundizar en el mundo de la fontanerfa, bastard decir que estas dos reglas estan 
relacionadas (obviamente): observe la similitud entre la parte then de la Regia 1 y la 
parte if de la Regia 2. Tal similitud es el fundamento para analizar la base de conocimien- 
tos (la cual tiene mucho mas que dos reglas). El motor de referenda podrfa iniciar con 
una solucidn potencial como “reemplazar el empaque” en la Regia 2, e ir en retrospectiva 
para ver los detalles del problema que demanda tal solucion. 

^De que manera el motor de deducciones “va en retrospectiva”? Analiza la parte if de la 
regia que tenga la solucion y busca una regia cuya parte then concuerde. En nuestro 
ejemplo de dos reglas, eso es facil: la Regia 1 tiene una parte then coincidente. En las 
aplicaciones de tono empresarial, esto no es tan sencillo debido a que una base de 
conocimientos podrfa almacenar cientos, tal vez miles, de reglas. 




Despues de que el motor de deducciones haya encontrado una regia, verifica si las condi- 
ciones de la parte if concuerdan con las condiciones del problema. Si es asi, el motor 
continua su busqueda en la misma direction: una parte then, verifica la parte if, otra 
parte then que concuerde y asi sucesivamente. Cuando el motor de deducciones se queda 
sin reglas, le pide mas information al usuario. La meta de ello es que si el trayecto por 
las reglas es exitoso (esto es, que concuerde con las condiciones del problema), el sis- 
tema ofrecera la solucion potencial original como la solucion al problema. Si no es el 
caso, el sistema intentara un nuevo trayecto. 

Esta tecnica de probar una solucion y verificar si las condiciones asociadas con- 
cuerdan con las condiciones del problema se conoce como encadenado regre- 
sivo\ “regresivo” porque inicia con las partes then y procede a examinar las partes if. 

Como podra imaginar, otra tecnica inicia con las partes if y corresponde con 
las partes then, y se conoce como encadenado progresivo. Asi es como tra- 
baja. El usuario establece las condiciones del problema y el motor de deducciones loca- 
liza una regia cuya parte if concuerde con las condiciones. Verifica la parte then y busca 
una regia cuya parte if concuerde con tal parte then. En nuestro ejemplo, suponga que la 
parte if de la Regia 1 concuerde con las condiciones del problema. El motor de deduc- 
ciones verifica la parte then de la Regia 1 y, luego, busca una regia con una parte if que 
concuerde. Nuevamente, esto es sencillo en nuestro caso con solo dos reglas. Cuando el 
sistema se queda sin reglas por comparar, ofrece las parte then de la regia final como la 
solucidn. La parte “progresiva” del “encadenado progresivo” se refiere a este 
movimiento de las partes if a las partes then. 

Si tuvieramos que modelar un sistema experto como en la figura 24.5, serfa de mucha 
ayuda agregar un estereotipo que indique el tipo de encadenamiento que realice el motor 
de deducciones. Agregarfamos ya sea «encadenamiento progresivo» o «encadenamiento 
regresivo» a la clase compuesta SistemaExperto. 



Termino Nuevo 



Termino Nuevo 




Ambos tipos de encadenamiento son ejemplos del patron de diseno Cadena 
de responsabilidades que vio anteriormente. En cada uno, el sistema busca a 
un "sucesor" de la regia. 

Asi como en ocasiones la Cadena de responsabilidades finaliza sin encontrar a 
un sucesor, un sistema experto tampoco le presentara siempre una solucion. 



Modelado de la base de conocimientos 

iQue es lo que puede agregar el UML a todo esto, y para que lo querrfamos? Uno de los 
puntos primordiales en el desarrollo de un sistema experto es la ausencia de una norma 
solida para generar una representacidn visual de las reglas de la base de conocimientos. 
Una representation basada en el UML podrfa requerir de un largo proceso para 






estandarizar el campo que propenda a buenas practicas de documentation. No es sufi- 
ciente que el conocimiento se encuentre en una representation informatica dentro de una 
base de conocimientos: las reglas deberfan estar tambien en un documento. 

^Como podrfamos representar a una base de conocimientos bajo el espiritu del UML? Es 
evidente que una posibilidad serfa la de representar cada regia como un objeto. Contar 
con uno de los atributos para que sea la parte if, otro la parte then y agregar otros atribu- 
tos conforme sea necesario. La figura 24.7 le muestra este diseno. 

Figura 24.7 

Representation de las 
reglas como objetos. 



Regia 1 

partelf = grifo que goteaY grifo de compuerta Y gotera en manija 
parteThen = Ajustar empaque 



Regia 2 

partelf = empaque ajustado Y aun hay gotera 
parteThen = cambiar empaque 



Aunque esto es eminentemente factible (y muchos desarrolladores lo hacen), creo que las 
reglas son muy importantes para garantizar su propia represen tacion. Ademas de ser el 
fundamento de las bases de conocimientos, el creciente enfasis en la administration del 
conocimiento dentro de las organizaciones e instituciones espera algo unico. 

^Cdmo podria lucir tal representation unica? Para empezar, necesitamos aseguramos que 
mostraremos algo que de el contenido de la parte if de la regia, y el de la parte then. Para 
hacer util a esta representation, tambien necesitamos algo para visualizar las conexiones 
entre las reglas. 

Esto podria dificultarse con rapidez. Las reglas de talla industrial tienden a contar con 
mayor information que las dos reglas de fontaneria que le mostre, y las reglas se inclinan 
a proliferar. Tenemos que balancear la proliferation respecto a la necesidad de la simpli- 
cidad. 

Primero cree un sencillo icono que represente a la regia. Empezaremos con un cuadro 
dividido a la mitad por una linea vertical. La mi tad izquierda representara a la parte if y 
la derecha a la parte then. Dentro de cada parte escribiremos un resumen significativo del 
contenido. La figura 24.8 le muestra lo que le quiero decir, con el ejemplo de las dos 
reglas de fontaneria. 



Figura 24.8 

Las dos reglas de 
fontaneria moldeadas 
en una representation 
visual. 



Compuerta con 
goteras 

Gotera en la manija 



Ajustar 

empaque 



Empaque ajustado 


Cambiar 


Gotera persiste 


empaque 








Ahora tenemos que incorporar cierta informacion de identification para cada regia. 
Agreguemos un compartimiento en la parte superior de cada cuadro que contenga un 
identificador numerico. Esto logra un par de cosas: (1) Convierte a cada regia en unica, y 
(2) muestra a donde ir en un catalogo de reglas para obtener una description y explication 
completa de la regia. Si una regia es parte de un subgrupo de reglas (como en un subcon- 
junto “grifo” de nuestra base de conocimiento de fontanerfa), podemos tratar al subgrupo 
como un paquete. Luego, agregar el paquete de informacion al identificador de la forma 
usual propia del UML: hacer que el nombre del paquete anteceda a un par de dos puntos 
(::), que antecedan al identificador. La figura 24.9 muestra tal adicion. 



Figura 24.9 

Adicion de un identifi- 
cador a cada regia. 



Grifos :: Regia 2 


Empaque ajustado 
Gotera persiste 


Cambiar 

empaque 



Grifos :: Regia 1 


Compuerta con 
goteras 

Gotera en la manija 


Ajustar 

empaque 



Ahora, representaremos la relacion entre los dos como una linea entre la parte then de la 
Regia 1 y la parte if de la Regia 2. La figura 24.10 le muestra la conexion. 



Figura 24.10 

Conexion de la parte 
then de una regia a la 
parte if de la otra. 



Grifos :: 


Regia 1 




Grifos :: 


Regia 2 


Compuerta con 
goteras 

Gotera en la manija 


Ajustar 

empaque 




Empaque ajustado 
Gotera persiste 


Cambiar 

empaque 











A diferencia de los dos conjuntos de pares de reglas, una regia en un sistema experto 
verdadero se relaciona usualmente a mas de una regia distinta. Si las reglas relacionadas 
no estan proximas — ya sea en la base de conocimientos o en la documentation — sera 
util tener una forma de mostrar la relacion aun cuando no podamos contar con Iineas de 
conexion. 

Los compartimientos de la parte baja del icono nos permitiran lograrlo. Si los colocamos 
por debajo de los que ya tenemos, podremos mostrar identificadores para otras reglas, 
como en la figura 24.1 1. El compartimiento inferior de la izquierda identifica a las reglas 
cuyas partes then se conectan con la parte if de esta. El compartimiento inferior de la 
derecha identifica reglas cuyas partes if se conectan con la parte then de esta. 





Figura 24.11 

Los compartimientos 
en la parte inferior del 
icono de la regia iden- 
tifican a las reglas 
relacionadas. 



Grifos :: Regia 1 




Grifos :: Regia 2 


Compuerta con 
goteras 

Gotera en la manija 


Ajustar 

empaque 


Empaque ajustado 
Gotera persiste 


Cambiar 

empaque 








10, 11, 15, Tuberia ::22 


2, 6, Lavabo ::22 


2, 13, Tuberia ::15 


17, 18, 31 



Como en el caso de los diagramas de clases, los compartimientos dentro del icono de la 
regia podrfan ser omitidos de acuerdo con el proposito del diagrama. La idea es mostrar 
de manera concisa las conexiones entre las reglas, asi como su contenido, y con ello 
comunicar con claridad la naturaleza de la base de conocimientos. 

El modelo del sistema experto es mas “drastico” que el de la GUI, en el sentido de que 
propone un nuevo “elemento de perspectiva” (el icono de regia) para el UML. El mo- 
delo para la GUI, por otra parte, es un diagrama hibrido que consta de elementos UML 
actuates . 

Eso es todo, amigos 

Hemos llegado al final del camino. Ahora que cuenta con todo un equipaje lleno de tru- 
cos del UML, ya esta listo para continuar por si mismo y aplicarlos a su dominio. Vera 
que conforme obtenga experiencia, hara adiciones a tal equipaje. Posiblemente tenga algu- 
nas sugerencias por agregar al UML. Si es su caso, continuara con una gran tradition. 

A principios del siglo XX, el renombrado matematico Alfred North Whitehead apunto la 
importancia de los simbolos y de su uso. Un simbolo, como indico, representa a una 
idea: la importancia de un simbolo es que rapida y concisamente muestra la forma en 
que una idea encaja en un complejo grupo de ideas diversas. 

Al principio de un nuevo milenio, las observaciones de Whitehead aun se aplican en el 
mundo del desarrollo de sistemas. Los simbolos cuidadosamente disenados nos muestran 
el proceso del raciocinio y las complejidades que hay detras de los maravillosos sistemas 
que intentamos generar, y nos ayudan a asegurar su rendimiento eficiente cuando los 
generemos. 



Resumen 

Conforme los modeladores extiendan y moldeen al UML para cumplir con sus necesi- 
dades, modelaran su propio futuro. En esta hora, hemos visto una extension para el mo- 
delado de los negocios y sugerf algunas formas de aplicar el UML en otras areas. 




Como leccion de la simplicidad de las extensiones de negocios, hemos explorado las for- 
mas de modelar las GUI y los sistemas expertos. Para modelar una GUI, establecemos un 
diagrama hibrido que muestre las relaciones de espacio de los componentes de la pan- 
talla, y que muestre sus conexiones y casos de uso. Esto tiene la ventaja de mostrar la 
evolution de una GUI conforme toma forma, y mantiene a los casos de uso correspon- 
dientes en el centro de la atencion. 

En un sistema experto, las reglas de condiciones (if-then) son el bloque de construction 
de una base de conocimientos, el componente que contiene el conocimiento de un experto 
en algun dominio humano. Sugerimos un diagrama que visualice las reglas y sus relaciones 
intemas. En este diagrama, un cuadro dividido en compartimientos modela a la regia. Un 
compartimiento contiene al identificador de la regia, otro resume la parte if, otro la parte 
then y otras dos muestran las reglas relacionadas. Los vinculos a las reglas adyacentes 
aparecen como lineas de conexion entre las partes adecuadas de las reglas. 

Preguntas y respuestas 

P Aunque en principio pareceria que un sistema experto no es dificil de modelar, 
parece que podria convertirse en un programa extremadamente dificil de 
escribir. 

R Lo sera si tiene que crear uno desde el inicio. Por fortuna, la mayor parte de la 
programacion la realiza usted en un paquete llamado shell para un sistema experto. 
Todos los componentes ya estan hechos. Tan solo debera agregar el conocimiento. 
No obstante, extraer el conocimiento de una persona experta no siempre es una 
tarea facil. 

P ^Que los vendedores de shells para sistemas expertos no tienen una notacion 
para representar a las reglas? 

R Si, y alii esta el problema. No hay una notacion que sea la estandar. 

Taller 

Las preguntas de este taller verificaran su conocimiento en la aplicacion del UML a las 
GUI y a los sistemas expertos. Las respuestas a los cuestionarios podran encontrarse en 
el Apendice A, “Respuestas a los cuestionarios”. 

Cuestionario 

1. ^Cuales son las ventajas de nuestro modelo de una GUI? 

2. ^Cuales son los componentes de un sistema experto? 

3. ^Que caracteristicas de un sistema experto comprende nuestro diagrama? 
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Apendice 

Respuestas a los 
cuestionarios 

Hora 1 

1 . ^Por que es necesario contar con diversos diagramas en el modelo de 
un sistema? 

Cualquier sistema cuenta con diversos usuarios con intereses distintos. 
Cada tipo de diagrama UML presenta una idea que podra ser compren- 
dida por cualquiera de los usuarios. 

2. ^Cuales diagramas le dan una perspectiva estatica de un sistema? 

Los diagramas de clases, objetos, componentes y distribution. 

3. ^Cuales diagramas le dan una perspectiva dinamica de un sistema 
(esto es, muestran el cambio progresivo)? 

Los diagramas de casos de uso, estados, secuencias, actividades y 
colaboraciones. 




Hora 2 

1. ^Que es un objeto? 

Un objeto es una instancia de una clase. 

2. ^Como trabajan los objetos en conjunto? 

Los objetos trabajan en conjunto mediante el envio de mensajes entre si. 

3. ^Que establece la multiplicidad? 

La multiplicidad establece la cantidad de objetos de una clase que se relacionan 
con otro de una clase asociada. 

4. ^Pueden asociarse dos objetos entre sf de mas de una manera? 

Si, por ejemplo: dos personas pueden estar asociadas como amigos y colaboradores. 

Hora 3 

1 . ^Como representa una clase en el UML? 

Con un rectangulo; el nombre de la clase se coloca dentro de el, en la parte superior. 

2. ^Que informacion puede mostrar en un sfmbolo de clase? 

Puede colocar los atributos, operaciones y responsabilidades de la clase. 

3 . ^Que es una restriccion? 

Es una regia y se escribe entre Haves. 

4. ^Para que adjuntarfa una nota a un simbolo de clase? 

Para agregar informacion que no se encuentra en los atributos, operaciones o 
responsabilidades. Por ejemplo, podrfa desear que el usuario del modelo lea un 
documento en particular que contenga informacion respecto a la clase. 

Hora 4 

1. ^Como representarfa la multiplicidad? 

En uno de los extremos de la linea de asociacion, coloque en el extremo lejano la 
cantidad de objetos que provienen de la clase que se relacionen con un objeto del 
extremo proximo. 

2. ^Cdrno descubrira la herencia? 

En la lista de clases de su modelo inicial, localice dos o mds clases que compartan 
atributos y operaciones. Ya sea que otra clase de su modelo inicial se convierta en 
la clase principal de las clases que comparten atributos, o que tenga que crear una 
clase principal. 




3. ^Que es una clase abstracta? 

Una clase abstracta es aquella que funciona como la base de la herencia, aunque no 
provee objetos. 

4. ^Cual es el efecto de un calificador? 

El efecto de un calificador es reducir una multiplicidad de uno a muchos a una de 
uno a uno. 

Hora 5 

1. ^Cual es la diferencia entre una agregacion y una composicion? 

Tanto una agregacion como una composicion especifican una asociacion de com- 
ponentes que conforman a un todo. En una agregacion, un componente puede ser 
parte de mas de un todo. En una composicion, un componente solo puede ser parte 
de un todo. 

2. iQue es la realization? 

Es la relation entre una clase y una interfaz. Se dice que la clase realiza las opera- 
ciones en la interfaz. 

3. Mencione los tres niveles de visibilidad y describa lo que significa cada uno de ellos. 

Si los atributos y operaciones de una clase tienen una visibilidad publica, pueden 
ser utilizados por otra. Si la visibilidad esta protegida, una clase secundaria (u otra 
descendiente) podrfa utilizarlos. Si son privados, solo la clase que los contiene 
podra utilizarlos. Las operaciones de una interfaz tienen una visibilidad publica. 

Hora 6 

1 . ^Como se llama a la entidad que inicia un caso de uso? 

Se denomina actor. 

2. ^Que se entiende con “incluir un caso de uso”? 

Se entiende que alguno de los pasos en una situation dentro de un caso de uso son 
los mismos que los de otro y en lugar de listar los mismos pasos, tan solo indica- 
mos el caso de uso de donde provienen. 

3. ^Que se entiende con “extender un caso de uso”? 

Se entiende que se agregan pasos a un caso de uso existente, y esto se hace para 
crear un caso de uso nuevo. 

4. ^Un caso de uso es lo mismo que un escenario? 

No. Un caso de uso es una coleccion de escenarios. 



Hora 7 

1 . Mencione dos ventajas de concebir un caso de uso. 

La primera ventaja de la visualization es que usted puede mostrar los casos de uso 
a los usuarios y lograr que le den information adicional, y la segunda ventaja es 
que puede combinar los diagramas de casos de uso con otro tipo de diagramas. 

2. Describa a la generalization y el agrupamiento, relaciones entre los casos de uso 
que ha visto durante esta hora. Mencione dos situaciones en las que usted agrupa- 
ria los casos de uso. 

En la generalization, un caso de uso hereda el significado y comportamientos de 
otro. El agrupamiento es la organization de un conjunto de casos de uso dentro 
de paquetes. 

3. ^Cuales son las similitudes entre las clases y los casos de uso? ^Cuales las diferencias? 

Similitudes: ambos son elementos estructurales. Ambos pueden heredar. Dife- 
rencias: La clase consta de atributos y operaciones. El caso de uso consta de esce- 
narios y cada uno consta de una secuencia de pasos. La clase proporciona una idea 
estatica de las partes del sistema, el caso de uso una idea dinamica. La clase mues- 
tra el interior del sistema. El caso de uso muestra el aspecto del sistema a alguna 
persona. 

Hora 8 

1 . ^De que forma difiere un diagrama de estados de uno de clases, de objetos o de 
casos de uso? 

Un diagrama de estados modela los estados de un solo objeto. Un diagrama de 
clases, de objetos o de caso de uso modela un sistema, o al menos parte de el. 

2. Defina los siguientes terminos: transition , suceso y action. 

Una transition es un cambio de un estado a otro. Un evento es un suceso que 
provoca una transition. Una action es un proceso ejecutable que resulta de un 
cambio de estado. 

3. iQue es una transition no desencadenadal 

Es una transition que ocurre por las actividades dentro de un estado, en lugar de 
ocurrir como respuesta a un evento. 

4. ^Cual es la diferencia entre los subestados secuenciales y los concurrentes? 

Los subestados son estados dentro de otros. Los subestados secuenciales suceden 
uno despues de otro. Los subestados concurrentes suceden al mismo tiempo. 




Hora 9 

1. Defina mensaje sincronico y mensaje asincronico. 

Cuando un objeto envia un mensaje sincronico, aguarda una respuesta antes de 
continuar. En el caso del mensaje asincronico, el objeto no aguarda una respuesta. 

2. En un diagrama de secuencias generico £Como representarfa el control de flujo 
implicito en una instruccion condicional? 

Se coloca la condicion entre corchetes. 

3. ^Como representarfa el control de flujo implicito en una instruccion de ciclo 
“mientras”? 

Se coloca la condicion entre corchetes y se antecede al corchete izquierdo con un 
asterisco. 

4. En un diagrama de secuencias ^Como representarfa a un objeto reci6n creado? 

Se representa por un rectangulo de objeto colocado en el tiempo de actividad (esto 
es, en algun lugar de la dimensidn vertical) de modo que su ubicaci6n represente el 
momento en que se haya creado en la secuencia. Agregue “Crear()” o «Crear» a la 
flecha del mensaje que apunte al objeto generado. 



Hora 10 

1 . ^Como representa un mensaje en un diagrama de colaboraciones? 

Por una flecha junto a la linea de asociacidn que une a un par de objetos. La flecha 
apunta al objeto receptor. 

2. ^Como mostrarfa informacion secuencial en un diagrama de colaboraciones? 

Adjuntaxido un numero al rotulo de una flecha de mensaje. El numero corresponde 
al orden secuencial del mensaje. 

3. ^Como mostrarfa los cambios de estado? 

Dentro del rectangulo de un objeto, indique su estado. Agregue otro rectangulo al 
objeto y muestre el estado modificado. Conecte a ambos con una linea punteada y 
rotule la linea con un estereotipo «se convierte en». 

4. ^Que se entiende por la “equivalencia semantica” de dos tipos de diagramas? 

Ambos tipos de diagramas muestran la misma informacion y podra convertir uno 
en otro. 



Hora 1 1 

1. ^Cuales son las dos formas de representar un punto de decision? 

Una de ellas es mostrar un rombo con bifurcaciones provenientes de el. La otra es 
mostrar las bifurcaciones provenientes directamente de una actividad. De cualquier 
forma, coloque una condition entre corchetes en cada ramification. 

2. ^Que es un marco de responsabilidad? 

En un diagrama de actividad, es un segmento que muestra las actividades que rea- 
liza algun rol en particular. 

3. ^Como representaiia la transmision y recepcion de una indicacion? 

Utilice un pentagono convexo para mostrar la transmision de una indicacion, y uno 
concavo para representar la recepcion. 

Hora 12 

1 . ^Cuales son los tres tipos de componentes? 

Son: componentes de distribucion, de producto de trabajo y de ejecucion. 

2. ^Como llamana a la relacion entre un componente y su interfaz? 

Se conoce como realization. 

3. ^Cuales son las dos formas de representar esta relacion? 

La primera muestra la interfaz como un rectangulo que contiene la information 
que se le relaciona, se conecta al componente por la linea discontinua y una punta 
de flecha representada por un triangulo sin rellenar que visualiza la realizacion. La 
segunda representara la interfaz como un pequeno circulo que se conecta al com- 
ponente por una linea continua. En este contexto, la linea representa la relacion de 
realizacion. 

4. ^Que es una interfaz de exportation ? ue es una interfaz de importation ? 

La interfaz de exportacion es una interfaz que un componente pone a disposicion 
de otros componentes de modo que puedan utilizar sus servicios. Cuando otro 
componente utiliza tales servicios, se convertira en una interfaz de importacion. 

Hora 13 

1 . ^Como representa a un nodo en un diagrama de distribucion? 

Con un cubo. 




2. ^Que tipo de information puede aparecer en un nodo? 

Puede estar el nombre del nodo, del paquete, y los componentes distribuidos en el 
nodo. 

3. ^Cuales son los dos tipos de nodos? 

Los procesadores (que pueden ejecutar componentes) y dispositivos (que se 
conectan con el mundo exterior). 

4. ^De que forma funciona una red token-ring? 

Esta red conecta a las computadoras equipadas con una tarjeta de red a una unidad 
central de accesso a multiestaciones a unidades de acceso a varias estaciones 
(MSAU) conectadas a manera de anillo. Las MSAU pasan una serial conocida 
como Token por el anillo. La position de la serial indica el equipo que puede 
enviar information en algun momento. 

Hora 14 

1. ^Cuales son las cuatro capas del UML? 

Son: la capa de objetos del usuario, la de modelo, la de metamodelo, y la de 
metametamodelo. 

2. ^Que es un clasificador? 

Es cualquier elemento que defina una estructura y comportamiento. 

3. ^Por que es importante poder extender al UML? 

Cuando empiece a utilizar el UML para modelar sistemas reales, se encontrara con 
situaciones que son mas amplias y complejas que las que vera en las referencias y 
libros de textos. Si puede extender el UML, podra reflejar la naturaleza de tales 
situaciones reales. 

4. ^Cuales son los mecanismos de extension del UML? 

Son los estereotipos, las restricciones y los valores rotulados o etiquetados. 

Hora 1 5 

1. ^Cuales son algunas de las inquietudes de un cliente? 

^E1 equipo de desarrollo comprendio el problema? ^Acaso los miembros del 
equipo comprenden la idea del cliente para resolverlo? ^Que productos del trabajo 
puede esperar el cliente del equipo de desarrollo? ^De que forma el administrador 
del proyecto informa al cliente? <,Que tanto puede profundizar el equipo en 
cualquier punto? 



2. ^Que se debe comprender como metodologia de desarrollo? 

Una metodologia de desarrollo establece la estructura y naturaleza de los pasos en 
un proyecto de desarrollo. 

3. ^,Cual es el metodo “en cascada”? ^Cuales son sus debilidades? 

En este metodo, el analisis, diseno, codification y distribucion son pasos secuen- 
ciales y no recurrentes. 

4. ^Cuales son los segmentos de GRAPPLE? 

Son: Recopilacion de necesidades, Analisis, Diseno, Desarrollo y Distribucion. 

5. ^Que es una sesidn JAD? 

Una sesion JAD (Desarrollo conjunto de aplicaciones) reune a quienes toman deci- 
siones dentro de la organization del cliente, a usuarios potenciales del sistema, y a 
los miembros del equipo de desarrollo. Algunas sesiones JAD conjugan al equipo 
de desarrollo con solo los usuarios. 

Hora 16 

1. <r,Cual diagrama del UML es adecuado para modelar un proceso del negocio? 

El diagrama de actividades. 

2. ^Como podna modificar este diagrama para mostrar que hace cada quidn? 

Puede utilizar el diagrama de actividades para agregarle marcos de responsabilidades. 
Cada responsable se coloca en la parte superior del marco que le corresponda. 

3. i,Qu€ debe entenderse por “ldgica de negocios”? 

Es un conjunto de normas que siguen los negocios en situaciones especfficas. 

Hora 17 

1. ^De que forma utilizaremos los sustantivos obtenidos en la entrevista con un 
experto? 

Los sustantivos se convierten en candidates para nombres de clases y de atributos. 

2. de que forma utilizaremos los verbos y construcciones verbales? 

Los verbos y construcciones verbales se convierten en candidates para operaciones 
y para asociaciones de nombres. 

3. lQu& es una asociacidn “tripartita”? 

Una asociacion tripartita involucra a tres clases. 




4. ^C6mo modelarfa una asociacidn tripartita? 

Mediante la vinculacidn de cada una de las clases en un rombo. Deberd escribir el 
nombre de la asociacidn cerca del rombo. Las multiplicidades en una asociacidn 
tripartita reflejan la cantidad de instancias de cualquier par de clases asociadas con 
una cantidad constante de instancias de la tercera. 

Hora 18 

1 . ^Cdrno hemos representado a las necesidades del sistema? 

Hemos usado el diagrama de paquetes junto con los casos de uso para lograrlo. 

2. ^Una vez que se hace el analisis del dominio ya finaliza el modelado de clases? 

El modelado de clases continua su desarrollo luego del andlisis del dominio. 

3. iQu€ es el “tiempo muerto”? 

Es el nombre que le he dado al tiempo que se pasa el mesero caminando por el 
restaurante. S61o quise ver si usted ponia atencidn 

Hora 19 

1. ^Cudles son las partes de un diagrama de casos de uso tipico? 

Son: el actor que inicia, el caso de uso, y el actor que se beneficia. 

2. qu6 se refiere que un caso de uso “incluya” (o “utilice”) a otro? 

“Incluir” un caso de uso significa que otro caso de uso incluye los pasos ya indicados 
en un caso de uso. 

Hora 20 

1. i,Como representaria a un objeto que se genera durante el curso de un diagrama de 
secuencias? 

Este objeto se representa coloc&ndolo bajo el nivel de los demas objetos. Mejorara 
la claridad si agrega un estereotipo «crear» al mensaje que antecede al objeto. 

2. ^Como se representa al tiempo en un diagrama de secuencias? 

El tiempo se representa con la linea de vida del objeto. 



3. ^Que es “la lfnea de vida”? 

Es una lfnea punteada que desciende de un objeto. Representa la existencia de un 
objeto en un cierto periodo. 

4. En un diagrama de secuencias, ^como muestra una “activacion” y que es lo que 
representa? 

Una activacion se representa como un pequeno rectangulo en el tiempo de activi- 
dad de un objeto. Representa el periodo durante el cual el objeto realiza alguna 
accion. 

Hora 21 

1. ^Qu6 es un analisis de tareas? 

Es un estudio que realiza un disenador de GUI para comprender lo que el usuario 
hara con la aplicacion que corresponda con la interfaz. 

2. ^Cual analisis de los que ya hemos hecho es un vago equivalente de un analisis de 
tareas? 

El analisis del caso de uso es equivalente al analisis de tareas. 

3. ^Que se entiende por un diseno de tipo “pantalon de payaso”? 

Es un diseno de GUI que incorpora una cantidad excesiva de colores, tamanos de 
componentes y fuentes. 

4. De tres razones para restringir el uso del color en una GUI. 

La primera razon es que la asociacion de un color con un significado podrfa no ser 
tan obvio para el usuario, como lo es para el disenador; en segundo lugar, demasia- 
dos colores distraerfan a los usuarios de la tarea por realizar; y finalmente, parte de 
la poblacion usuaria podrfa sufrir de daltonismo. 

Hora 22 

1. ^Como representarfa una clase parametrizada? 

Se utiliza la representation normal de la clase con un pequeno recuadro sobre- 
puesto en la esquina superior derecha. El pequeno recuadro esta formado de lfneas 
punteadas. 

2. ^Que es “vincular” y cuales son los dos tipos de vinculacion? 

La “vinculacion” es la accion de adjuntar un valor a un parametro. Los dos tipos de 
vinculacion son “explfcita” e “implfcita”. 

3. <^Que es un “patron de diseno”? 

Un patron de diseno es una solucion probada a un problema de diseno. Se puede 
utilizar en diversas situaciones, y en el UML lo representa como una colaboracion 
parametrizada. 




4. ^Que es el patron de diseno “Cadena de responsabilidades”? 

En este patron de diseno, un objeto cliente inicia una peticion y la pasa al primero 
en una cadena de objetos. Si el primero de ellos no puede responder a la peticion, 
la pasa al siguiente. Si tampoco la puede responder, la pasara al siguiente, y asi 
hasta que un objeto pueda responder a la peticidn. 

Hora 23 

1. ^Que es un sistema incrustado? 

Es un sistema de computo que se encuentra dentro de algun otro tipo de disposi- 
tivo, como un electrodomestico. 

2. ^Que es un evento asincronico? 

Un evento es asincronico cuando no se puede predecir en que momento sucedera. 

3. En terminos de sistemas incrustado, ^que es un sistema “estricto” y que es un sis- 
tema “tolerante”? 

Un sistema estricto debe cumplir con tiempos especificos, en tanto que el tole- 
rante no. 

4. ^Que sucede en un “nucleo preferential”? 

En este tipo de nucleo, luego que se ejecuta una ISR, la CPU no regresa al subpro- 
ceso interrumpido si hay un subproceso de mayor prioridad en estado de Listo. En 
vez de ello, ejecutara al subproceso de mayor prioridad. 

Hora 24 

1. ^Cuales son las ventajas de nuestro modelo de una GUI? 

Nuestro modelo puede capturar nuestros procesos conceptuales en la evolution de 
una GUI y centra la atencion en los casos de uso conectados con cada pantalla. 

2. ^Cuales son los componentes de un sistema experto? 

Son: base de conocimientos, area de trabajo y motor de interfaz. 

3. ^Que caracterfsticas de un sistema experto comprende nuestro diagrama? 

Nuestro diagrama muestra las partes de una regia, las reglas asociadas y las rela- 
ciones entre reglas. 



Apendice 

Herramientas de 
modelado para el UML 

Conforme ley 6 el tema del libro y realizd los ejercicios, posiblemente utilizd 
un ldpiz y papel para crear sus diagramas. Si necesitara hacerlo en sus pro- 
cesos de modelado relacionados con proyectos, pronto se encontrarfa con 
problemas. Adem&s de tener que dibujar todas esas lineas, circulos, elipses y 
rect&ngulos, tendrd dificultades cuando desee modificar la disposicidn de un 
diagrama ya terminado. 

Afortunadamente, la tecnologfa viene al rescate. Existen diversas herramien- 
tas que le pueden ayudar a crear modelos UML. Este apendice le hablara de 
tres de ellas: Rational Rose, SELECT Enterprise y Visual UML. No veremos 
todas sus caracterfsticas y opciones, sin embargo veremos un poco de cada 
una para que tenga una idea general de la forma en que funcionan y lo que 
hacen. 




Caracterfsticas en comun 

Aunque estas herramientas tienen caracterfsticas muy diversas, cuentan con 
algunas caracterfsticas en comun. Cada una permite una diagramacidn de 



tipo “banda eldstica”: al crear un vinculo entre dos elementos, este se ajustara cuando 
los arrastre por la pantalla. Cada uno permite al menos cierta generacion de codigo, con lo 
que se producen pequenas secciones de codigo a partir de los modelos. Finalmente, todos 
ellos cuentan con extensas herramientas y cuadros de dialogo para las modificaciones. 

Rational Rose 

El lider del mercado en las herramientas de modelado, Rational Rose, es un producto de 
la empresa que da empleo a los Tres Amigos. 

Cuando ejecute el programa, vera la ventana de la figura B.l. Como podra ver, las demas 
herramientas tendran ventanas similares. 



Figura B.l 

Pantalla inicial de 
Rational Rose. 




El panel de la izquierda es el examinador y el de la derecha contiene la ventana de dia- 
gramacion; entre ellos se encuentra una paleta de iconos UML para un diagrama de 
clases, el cual es el tipo de diagrama que se abre de forma predeterminada. 

El examinador esta organizado de acuerdo con vistas: vista de Caso de uso, vista Logica, 
vista de Componentes, y vista de Distribution. Para crear un diagrama, debera hacer clic 
con el boton derecho en las vistas, y las opciones de diagramacidn relacionadas con ellas 
apareceran en un menu. Seleccione una y aparecera una nueva ventana de diagramacion. 
Tambien contara con una paleta de iconos adecuada para el diagrama que utilice. La 
figura B.2 muestra un diagrama de casos de uso y su paleta. 



Figura B.2 

Un diagrama de casos 
de uso y su paleta en 
Rose. 




Rose agrega cierto dinamismo a sus iconos. Cuando desee mostrar los atributos y las 
operaciones de una clase como publicos, privados o protegidos, podra agregarles distin- 
tivos visuales como los que aparecen en la figura B.3. 



Figura B.3 

Rose establece algunos 
distintivos visuales 
para los iconos de 
clases. 




Para obtener una mayor information de Rational Rose, visite http : / /www. rational . com. 





SELECT Enterprise 

Como su nombre lo indica, SELECT Enterprise se ha diseiiado para ser una herramienta 
de modelado para toda una empresa. En ese sentido, automdticamente se conecta con 
un depdsito en red donde es accesible para los modeladores y los usuarios de los modelos 
de toda una empresa. Las ventajas de utilizar un dep6sito son que se lleva un control de 
las personas que acceden a los modelos y permite llevar un control de versiones. 

Cuando abra un modelo, la ventana de SELECT (vea la figura B.4) cargard un entomo 
parecido al de Rose, pero sdlo hasta alii queda la similitud. Ambas herramientas tienen 
diferentes perspectivas: mientras que Rose se enfoca estrictamente en el UML, en el 
esquema de cosas de SELECT, el UML es uno de varios paquetes de modelado impor- 
tantes. SELECT Enterprise le permite utilizar conjuntos de sfmbolos que no son de UML 
para dibujar modelos de datos y generar modelos de procesos de negocios. 

Figura B.4 

La pantalla de 
SELECT Enterprise 
cuando se abre un 
modelo. 




La ventana de exploracidn de SELECT es el equivalente al examinador de Rose. Consta 
de cuatro fichas. Una de ellas contiene el diccionario de su modelo, la otra le permite 
crear sus diagramas de modelado. La tercer ficha le ayuda a organizar sus diagramas, y 
cuarta que le otorga ayuda. 

La figura B.5 le muestra un diagrama de clases en SELECT. Observe los estereotipos de 
«business»: aparecen de forma predeterminada cuando usted genera una clase. 




Figura B.5 

Un diagrama de closes 
en SELECT. 




Aparte de su propio funcionamiento intrinseco, un diagrama de clases de SELECT es 
importante por otra razdn: SELECT le permite crear un diagrama de estados s61o si ya 
ha creado una clase por adjuntarle. La figura B.6 le muestra un diagrama de estado. 
Observe el nombre de la clase del diagrama de estados en la esquina superior izquierda 
del diagrama. 



Figura B.6 

Un diagrama de 
estados en SELECT. 









Para enriquecer su modelo, puede vincular elementos de modelado entre si. Tambien 
podr£ vincular diagramas y podra ejecutar un informe que muestre cuales diagramas 
est£n vinculados a uno en particular. 

Cuando escribi estas lineas, SELECT Enterprise no permitfa el uso de diagramas de 
actividades, de componentes o de distribution. Para mayor information de SELECT 
Enterprise, dirfjase al sitio http: //www. selectst.com. 

Visual UML 

Cuando ejecute Visual UML (vea la figura B.7), vera una interfaz ordenada, la cual le 
aparecerd con toda simplicidad. Si conoce algo de UML, estar£ dibujando diagramas en 
Visual UML en muy poco tiempo. 




El panel de tipo explorador y examinador del extremo izquierdo de la ventana del 
Visual UML es un mecanismo para crear y administrar los diagramas. Todos los tipos 
de diagramas estan en el nivel superior. Siempre estara a tan solo un par de dies del 
raton para crear un diagrama. 

La figura B.8 le muestra la paleta y la ventana para crear un diagrama de clase. Las pale- 
tas de esta herramienta otorgan cierta facultad de utilizar imagenes que no son del UML, 
dado que le permiten dibujar recuadros y lineas en el diagrama. 




Figura B.8 

Creadon de un dia- 
grama de dases en 
Visual UML. 




Cabe hacer notar que po<M vincular los objetos de un diagrama con los de otro. 

Visite http : / /www . visualuml . com para conocer mayores detalles de Visual UML. 

La herramienta ideal para el modelado 

Cada una de estas herramientas de modelado cuenta con una buenas caracterfsticas; pero 
aun asi, pienso que se les podrfan agregar mas. 

Una de ellas podrfa ser flexibilidad. Con frecuencia quisiera utilizar los iconos de un 
tipo de diagrama en otro para asi conformar un diagrama hfbrido. Los iconos de estado 
podrfan ser muy utiles en un diagrama de secuencias. La representation de un Actor en 
un diagrama de casos de uso podrfa ser muy util en otros diagramas. Aunque esta podrfa 
ser una facultad muy dificil de incorporar, pagarfa enormes dividendos entre los mode- 
ladores. 

Otra caracterfstica que me gustarfa ver es... mayor flexibilidad. Ademas de importar 
iconos de un tipo de diagrama a otro, me gustarfa poder importar imagenes predisenadas 
y utilizarlas como estereotipos graficos en los diagramas. Quiza algunas imagenes uti- 
lizadas con frecuencia podrfan incluirse en la herramienta. 

Finalmente, un manual de instruccion metodico y con cierta animation podrfa ser de 
mucha utilidad en cualquier herramienta de modelado. El manual de instruccion podrfa 
presentar ideas elementales respecto al UML y mostrar como se orientan dentro de las 
facultades propias de la herramienta de modelado. Esto podrfa convertirse en un exce- 
lente servicio para las personas que recien ingresan al mundo del modelado. 
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Un resumen grafico 

Este apendice presenta algunos de los aspectos primordiales de cada 
diagrama UML. 



Diagrama de actividades 









Figura C.2 



Figura C.3 









Diagrama de dases 



Figura C.4 
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Nombre del rol en una asociacion 






Figura C.5 



Asociacion tripartita: 










Diagrama de colaboraciones 



Figura C.6. 





Diagrama de componentes 




Componente 2 







Diagrama de distribution 



Figura C.8 




Diagrama de secuencias 
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Diagrams de estados 



Figura C.10 









